Programación General > ASM (Ensamblador)

 Programar La Gpu

<< < (6/9) > >>

bob esponja:
lo de bienvenido a la programacion no es poque seas nuevo sino porque tenes que tomar las cosas con calma y hacer avances chicos

obvio que a todos nos gustaria escribir todo lo que vos decis pero ni siquiera se me ocurre empezar a escribir una linea de eso porque se que si lo empiezo ahora no va a funcionar  

lo de las cosas "simples" que hice no es sarcasmo es en serio nunca logre programar algo totalmente completo sino que hice cosas incompletas con el fin de aprender en el proceso despues de varios fallos y con un proceso "iterativo e incremental" (paresco mis profesores) se puede lograr algo pero la regla general es que si apuntas a algo muy alto de entrada nunca lo terminas....

espero ver avances tuyos por aca

si ya hiciste algo estaria bueno que lo postees

no es de amargo es que me ha pasado de encarar un proyecto muy grande y no llegar a nada y te da bronca

CodigoDavid:

--- Cita de: "bob esponja" --- lo de bienvenido a la programacion no es poque seas nuevo sino porque tenes que tomar las cosas con calma y hacer avances chicos

obvio que a todos nos gustaria escribir todo lo que vos decis pero ni siquiera se me ocurre empezar a escribir una linea de eso porque se que si lo empiezo ahora no va a funcionar  

lo de las cosas "simples" que hice no es sarcasmo es en serio nunca logre programar algo totalmente completo sino que hice cosas incompletas con el fin de aprender en el proceso despues de varios fallos y con un proceso "iterativo e incremental" (paresco mis profesores) se puede lograr algo pero la regla general es que si apuntas a algo muy alto de entrada nunca lo terminas....

espero ver avances tuyos por aca

si ya hiciste algo estaria bueno que lo postees

no es de amargo es que me ha pasado de encarar un proyecto muy grande y no llegar a nada y te da bronca
--- Fin de la cita ---
por curiosidad, cual era ese proyecto que no pudiste terminar?(ya se lo que quieres decir con lo de que da bronca, me ha pasado alguna vez......), por cierto, y como he dicho, lo que pregunte en mi post es para el futuro........., ahora de momento estoy creando en C++ unas clases y funciones que tengan bastante "robustez"(esto es, bien diseñado)para poder despues hacer cosas de mas alto nivel de forma mucho mas facil, esta clase que estoy haciendo es del tema de la memoria, mas que nada se encarga de registrar, al momento de asignar memoria a un puntero, la direccion de este y tambien su tamaño en bytes, empeze a hacer esto por que un dia me encontre con un problema, el operador sizeof te dice el numero de elementos que tiene una matriz estatica pero no una dinamica, esto es, para los punteros siempre da el mismo valor, tenga la matriz 10 elementos o 300 o 50000 que siempre dara lo mismo(da siempre el tamaño de palabra del procesador), y entonces, si programas en c++ sabras que este no tiene algo similar a la funcion realloc como el C, y por lo que me han dicho, aun que pueda utilizar realloc en C++, se ve que es mejor no mezclar el tema de la memoria en como lo utiliza C con C++, y entonces, claro, vas todo contento y piensas, pues hago una funcion que internamente copie temporalmente el contenido del puntero al que se le tiene que agrandar la capacidad, libero la memoria de este, vuelvo a asignarle la memoria necesaria y le copio otra vez el contenido que tuviera, peroooooo............vuelves dos pasos anteriores y te fijas que...........!!!ostias, y como se el numero de elementos que tiene el puntero?!!!
si es con una cadena vale, por que tiene el delimitador del caracter \0 y a partir de ahy puedes saber el numero de elementos, pero no es posible con una matriz numerica, por que el 0 es tambien un valor "normal y corriente", entonces no puedes saber su longitud, y bueno, pues se me ocurrio hacer una funcion que asigna memoria y esta internamente registra la direccion de memoria del puntero pasado como parametro y la longitud asignada(tambien pasada como argumento), entonces, la funcion de reasignar memoria solo se tiene que consultar lo que registro la funcion de asignar memoria para saber el numero de elementos de ese puntero, y encima no puede haber problemas de direcciones de memoria por que de direccion de memoria solo hay una de cada, osea, de direcciones de memoria "34343" solo hay una, no existen dos direcciones de memoria "34343", y entonces ya.........................es solo cuestion de construir unas bases solidas, y creo que la memoria es uno de los temas principales, cuando tenga cosas echas ya las posteare :comp:  :hola:

furiouslogic:
Interesante charla y solo acotar algo sobre programacion de graficos bajo DOS. Me refiero a que no se debe confundir el programar graficos utilizando el driver VESA para DOS con programar graficos utilizando la especificacion VESA. En el primer caso requiere de un driver, un archivo aparte. En el segundo caso tenemos el uso de una interrupcion (metodo lento) o el acceso directo a direcciones de memoria que en modos VESA depende del fabricante.  Por este motivo programar un juego en modos VESA sin driver era un dolor de cabeza porque tenias que buscar mil especificaciones de fabricantes para determinar las direcciones para sus respectivos modelos de tarjeta y encima marcas.

  Algo mas, programar con acceso directo a memoria grafica no es para nada lento.  Por el contrario, es lo mas rapido que existe puesto que estamos escriiendo directamente en los chips de memoria de la tarjeta grafica ¿Existe algo mas rapido? Posiblemente si, la telepatia, pero hasta alli no ha llegado la programacion  :D


saludos y si que preguntas ah,


Furious Logic [aRC]

CodigoDavid:

--- Cita de: "furiouslogic" --- Interesante charla y solo acotar algo sobre programacion de graficos bajo DOS. Me refiero a que no se debe confundir el programar graficos utilizando el driver VESA para DOS con programar graficos utilizando la especificacion VESA. En el primer caso requiere de un driver, un archivo aparte. En el segundo caso tenemos el uso de una interrupcion (metodo lento) o el acceso directo a direcciones de memoria que en modos VESA depende del fabricante.  Por este motivo programar un juego en modos VESA sin driver era un dolor de cabeza porque tenias que buscar mil especificaciones de fabricantes para determinar las direcciones para sus respectivos modelos de tarjeta y encima marcas.

  Algo mas, programar con acceso directo a memoria grafica no es para nada lento.  Por el contrario, es lo mas rapido que existe puesto que estamos escriiendo directamente en los chips de memoria de la tarjeta grafica ¿Existe algo mas rapido? Posiblemente si, la telepatia, pero hasta alli no ha llegado la programacion  :D


saludos y si que preguntas ah,


Furious Logic [aRC]
--- Fin de la cita ---
Pues claro que existe algo mas rapido, el agp y programar las operaciones graficas utilizando el PROPIO procesador de la targeta grafica..................que es lo que yo quiero hacer.........

furiouslogic:
Parece que no leiste con detenimiento lo que indique. Lo resumiremos así:
¿Desde donde lee los datos el GPU? Desde la memoria que lleva en la tarjeta. No hablo de la ram hablo de los chips de memoria que vienen en toda tarjeta grafica.  Esa es la forma mas rapida de escribir graficos.

Cuando deseamos enviarle datos al GPU, en el DOS en lugar de utilizar interrupciones utilizabamos escritura directa en memoria. Leiste la parte en que escribi "solo acotar algo sobre programacion de graficos bajo DOS".

Ahora bien, el tema bajo Windows es distinto y mas facil en cierto modo. OpenGL es un standard tan bueno que aun sigue en la version 1.x en tanto que DirectX ya va por la 10 y requiere instalar como 30 MiB para tener la 9.0c que tengo entendido que es la ultima. Bueno, no quiero destapar el tema de OpenGL vs DirectX porque de hecho se arma la discusion. El punto es que sea que uses OpenGL o uses DirectX, estas accediendo directamente al hardware.  Esa es la idea de ambas librerias y de alli mi comentario sobre la dificultad de la programacion bajo DOS-especificacion VESA vs los distintos modelos-marcas de tarjetas.  Es decir, que bajo windows, se intento evitar todo ese lio de averiguar marcas, direcciones de memoria particulares y todo ese rollo, y se crearon OpenGL por un lado DirectX por otro lado. Ambas se encargar de determinar la mejor forma de acceso directo al hardware. De este modo ya no tienes que preocuparte por averigual la informacion no documentada sobre en que direccion de memoria escribir si es la tarjeta Perico 8000, Coquito ABC o Fulano "Budú".  Simplemente le dices a la API si es OpenGL o al objeto COM si es DirectX que escriba un pixel y listo, asunto arreglado ellos se encargan de averiguar que es mas rapido.
Los fabricantes de tarjetas envian esa informacion a Microsoft que para nosotros en DOS era rebuscada, no documentada o como sea.  De alli que es improbable que al menos 1 compáñia te vaya a dar gratis su informacion privada. (Microsoft paga por esa informacion y paga en serio, aunque nos cobra mucho mas de lo que paga)

Volviendo a tu tema grafico. Tienes 2 alternativas: la primera es crear un kernel que base su parte grafica en la informacion que las corporaciones graficas te hagan llegar a ti.
La segunda es que hagas un kernel que base su parte grafica en los drivers existentes de Windows o en los de Linux.

Es un tema bastante complicado para que empiezes a crear algo. Es admirable tu emocion por crear algo asi pero de alli a la realidad, pues te diria que le des una miradita al codigo de un kernel, el mas simple que exista y a ver como vamos.

suerte y empieza por algo mas a tu alcance,


saludos,


Furious Logic [aRC]
www.arc3000.com
(SITE CENSURADO)


PD: Te sugeriria que leas la enorme cantidad libros que tenemos en la web pero nos censuraron hace tan solo 2 semanas. Si tienes paciencia, en un tiempo migramos todo a un nuevo servidor y alli podras leer libros de programacion hasta que termines pensando en binario y hablando en hexadecimal  :D

Navegación

[0] Índice de Mensajes

[#] Página Siguiente

[*] Página Anterior

Ir a la versión completa