• Jueves 28 de Marzo de 2024, 15:00

Autor Tema:  Programar La Gpu  (Leído 33149 veces)

bob esponja

  • Miembro MUY activo
  • ***
  • Mensajes: 411
    • Ver Perfil
    • http://marianoguerra.blogspot.com
Re: Programar La Gpu
« Respuesta #25 en: Viernes 1 de Julio de 2005, 06:06 »
0
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

  • Nuevo Miembro
  • *
  • Mensajes: 21
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #26 en: Viernes 1 de Julio de 2005, 23:55 »
0
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
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

  • Nuevo Miembro
  • *
  • Mensajes: 19
    • Ver Perfil
    • http://www.arc666.com
Re: Programar La Gpu
« Respuesta #27 en: Miércoles 6 de Julio de 2005, 01:25 »
0
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

  • Nuevo Miembro
  • *
  • Mensajes: 21
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #28 en: Miércoles 6 de Julio de 2005, 23:05 »
0
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]
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

  • Nuevo Miembro
  • *
  • Mensajes: 19
    • Ver Perfil
    • http://www.arc666.com
Re: Programar La Gpu
« Respuesta #29 en: Jueves 7 de Julio de 2005, 23:15 »
0
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

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: Programar La Gpu
« Respuesta #30 en: Viernes 8 de Julio de 2005, 04:41 »
0
hola CodigoDavid

Solo ten presente que te han hablado con consejos muy practicos y queno han adquirido de la noche a la mañana...
muchos hemos sido los que hemos querido iniciar por la senda que pretendes ... para despues de un tiempo darnos cuenta que no ea la manera correcta de empezar...
sigue el consejo de los que ya han pasado por ahi...

cuando el rio suena...
piedras lleva.
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

CodigoDavid

  • Nuevo Miembro
  • *
  • Mensajes: 21
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #31 en: Sábado 9 de Julio de 2005, 02:59 »
0
Cita de: "JuanK"
hola CodigoDavid

Solo ten presente que te han hablado con consejos muy practicos y queno han adquirido de la noche a la mañana...
muchos hemos sido los que hemos querido iniciar por la senda que pretendes ... para despues de un tiempo darnos cuenta que no ea la manera correcta de empezar...
sigue el consejo de los que ya han pasado por ahi...

cuando el rio suena...
piedras lleva.
Ok, lo que pasa es que a mi esto de utilizar librerias ya "prefabricadas" supongo que tambien tienen sus limitaciones, y entonces, si hay algo que quieres hacer pero no esta implementado en la API pero tampoco lo puedes programar directamente en el hardware por que el sistema no te deja que haces? no creo que hayga muchas limitaciones hoy en dia con la cantidad de cosas que tienen las API pero siempre hay excepciones..........................y mi mayor dificultad es que no se por donde empezar, supongo que primero seria estudiar la api de windows, y luego DirectX o OpenGL, pero, y mi talon de aquiles es el mega-ultra-super-bajo nivel de ingles que tengo :unsure: y claro, cuanto tiempo cuesta aprender un ingles decente? 1 año? pffff...... y tambien me encuentro por internet algunos tutoriales que alomejor pone la descripcion por ejemplo de la estructura WNDCLASSEX asi:


"
cbSize
El tamaño de la estructura
style
El estilo de la clase (CS *), no confundirse con el estilo de la ventana (WS *). Generalmente este campo puede ser puesto en cero.
lpfnWndProc
Puntero al Window Procedure de esta clase.
cbClsExtra
Cantidad extra de asignación de memoria para datos de la clase. Generalmente cero.
cbWndExtra
Cantidad extra de asignación de memoria por ventana de este tipo. Generalmente cero.
hInstance
Handle a la instancia de la aplicación (la que obtenemos en el primer parámetro de WinMain( ) )
hIcon
Handle al ícono grande (32x32), mostrado cuando el usuario presiona Alt+Tab.
hCursor
Handle al cursor que será mostrado sobre la ventana.
hbrBackground
Pincel para fijar el color de fondo de nuestra ventana.
lpszMenuName
Nombre del recurso Menú para usar con las ventanas de esta clase.
lpszClassName
Nombre para identificar la clase.
hIconSm
Handle al ícono pequeño (16x16), usado en la barra de tareas y en la esquina superior izquierda de la ventana.
"

vale, ok, bien, pero para que sirve concretamente cbClsExtra? es que dice que es generalmente 0, vale, generalmente, pero por que no dice exactamente para que sirve? ami esta falta de informacion es lo que me "mata" en esto de la programacion................estos son en resumen con los problemas con los que me encuentro con el API de windows :alien:

Eternal Idol

  • Moderador
  • ******
  • Mensajes: 4696
  • Nacionalidad: ar
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #32 en: Sábado 9 de Julio de 2005, 08:56 »
0
Cita de: "CodigoDavid"
Ok, lo que pasa es que a mi esto de utilizar librerias ya "prefabricadas" supongo que tambien tienen sus limitaciones, y entonces, si hay algo que quieres hacer pero no esta implementado en la API pero tampoco lo puedes programar directamente en el hardware por que el sistema no te deja que haces? no creo que hayga muchas limitaciones hoy en dia con la cantidad de cosas que tienen las API pero siempre hay excepciones..........................y mi mayor dificultad es que no se por donde empezar, supongo que primero seria estudiar la api de windows, y luego DirectX o OpenGL, pero, y mi talon de aquiles es el mega-ultra-super-bajo nivel de ingles que tengo :unsure: y claro, cuanto tiempo cuesta aprender un ingles decente? 1 año? pffff...... y tambien me encuentro por internet algunos tutoriales que alomejor pone la descripcion por ejemplo de la estructura WNDCLASSEX asi:

vale, ok, bien, pero para que sirve concretamente cbClsExtra? es que dice que es generalmente 0, vale, generalmente, pero por que no dice exactamente para que sirve? ami esta falta de informacion es lo que me "mata" en esto de la programacion................estos son en resumen con los problemas con los que me encuentro con el API de windows :alien:

Cuando quieras hacer algo muy especifico pensa en hacer un driver que se ejecute en modo kernel, por lo menos si queres que sea usado por mas de cinco personas en el mundo.

En cuanto a lo de la API lo lamento mucho pero tengo que decir que es tu culpa. Ese campo en particular esta explicado al detalle en la MSDN:

cbClsExtra
Specifies the number of extra bytes to allocate following the window-class structure. The system initializes the bytes to zero.


¿Que significa esto? Este campo especifica el numero (cantidad) de bytes extra para reservar justo despues de la estructura de la Ventana. El sistema INICIALIZA los bytes a cero, eso quiere decir que la memoria esta toda puesta a cero, cada uno de sus bytes.
La ayuda que tenes dice que generalmente se inicializa a cero porque la gente o no necesita guardar variables de la ventana o utiliza otros metodos.

Realmente yo me saco el sombrero ante la MSDN y el DDK, si tuviera que programar en Linux con el man mi vida seria mucho mas complicada  :smartass:

Nacional y Popular En mi país la bandera de Eva es inmortal.


Queremos una Argentina socialmente justa, económicamente libre y  políticamente soberana.
¡Perón cumple, Evita dignifica!


La mano invisible del mercado me robo la billetera.

CodigoDavid

  • Nuevo Miembro
  • *
  • Mensajes: 21
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #33 en: Sábado 9 de Julio de 2005, 19:02 »
0
Cita de: "Eternal Idol"
Cita de: "CodigoDavid"
Ok, lo que pasa es que a mi esto de utilizar librerias ya "prefabricadas" supongo que tambien tienen sus limitaciones, y entonces, si hay algo que quieres hacer pero no esta implementado en la API pero tampoco lo puedes programar directamente en el hardware por que el sistema no te deja que haces? no creo que hayga muchas limitaciones hoy en dia con la cantidad de cosas que tienen las API pero siempre hay excepciones..........................y mi mayor dificultad es que no se por donde empezar, supongo que primero seria estudiar la api de windows, y luego DirectX o OpenGL, pero, y mi talon de aquiles es el mega-ultra-super-bajo nivel de ingles que tengo :unsure: y claro, cuanto tiempo cuesta aprender un ingles decente? 1 año? pffff...... y tambien me encuentro por internet algunos tutoriales que alomejor pone la descripcion por ejemplo de la estructura WNDCLASSEX asi:

vale, ok, bien, pero para que sirve concretamente cbClsExtra? es que dice que es generalmente 0, vale, generalmente, pero por que no dice exactamente para que sirve? ami esta falta de informacion es lo que me "mata" en esto de la programacion................estos son en resumen con los problemas con los que me encuentro con el API de windows :alien:

Cuando quieras hacer algo muy especifico pensa en hacer un driver que se ejecute en modo kernel, por lo menos si queres que sea usado por mas de cinco personas en el mundo.

En cuanto a lo de la API lo lamento mucho pero tengo que decir que es tu culpa. Ese campo en particular esta explicado al detalle en la MSDN:

cbClsExtra
Specifies the number of extra bytes to allocate following the window-class structure. The system initializes the bytes to zero.


¿Que significa esto? Este campo especifica el numero (cantidad) de bytes extra para reservar justo despues de la estructura de la Ventana. El sistema INICIALIZA los bytes a cero, eso quiere decir que la memoria esta toda puesta a cero, cada uno de sus bytes.
La ayuda que tenes dice que generalmente se inicializa a cero porque la gente o no necesita guardar variables de la ventana o utiliza otros metodos.

Realmente yo me saco el sombrero ante la MSDN y el DDK, si tuviera que programar en Linux con el man mi vida seria mucho mas complicada  :smartass:
Sabes si la MSDN esta en español?

PD: Va ser que no.....

Eternal Idol

  • Moderador
  • ******
  • Mensajes: 4696
  • Nacionalidad: ar
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #34 en: Sábado 9 de Julio de 2005, 19:09 »
0
Que yo sepa no, por eso te comentaba en mensajes anteriores que es imprescindible entender Ingles tecnico ya que la mayoria de la documentacion esta en ese idioma y ni hablar de las cosas que van saliendo.

 :smartass:

Nacional y Popular En mi país la bandera de Eva es inmortal.


Queremos una Argentina socialmente justa, económicamente libre y  políticamente soberana.
¡Perón cumple, Evita dignifica!


La mano invisible del mercado me robo la billetera.

bob esponja

  • Miembro MUY activo
  • ***
  • Mensajes: 411
    • Ver Perfil
    • http://marianoguerra.blogspot.com
Re: Programar La Gpu
« Respuesta #35 en: Lunes 11 de Julio de 2005, 05:39 »
0
no me gusta empezar otro flamewar pero tampoco me gustan las injusticias,
comparar MSDN con el man es como comparar el notepad con openoffice ( para que no surja otro flamewar agrego: office es mucho mejor que openoffice pero con openoffice me sobra ).

el man es una simple documentacion sobre PROGRAMAS explicando su funcionamiento y los parametros que se le pasan con una breve explicacion.

queres las APIS:

la que usa gnome (gtk): http://www.gtk.org/api/
la que usa Kde (qt): http://doc.trolltech.com/3.3/
la de c para linux: www.srsplus.com/en-def-d82f4a834d85/ en/srsplus/api_c_linux.pdf
la de python: docs.python.org/api/api.html
la del kernel: kernelnewbies.org/documents/ kdoc/kernel-api/linuxkernelapi.html

y asi puedo seguir,m no te preocupes que uno de los fuertes del opensource es que hay documentacion de sobra  para las aplicaciones y librerias extendidas lo que pasa es que no estan en una sola pagina ( o si... en google ), te recomiendo esto

www.google.com
pone xxx API reference
www.google.com/linux
pone xxx API reference

y va a aparecer mucha documentacion.

la primera vez que lei la comparacion de MSDN  con el man la deje pasar, pero esta mal que a los que recien empiezan se los asuste con "el monstruo de linux"

Eternal Idol

  • Moderador
  • ******
  • Mensajes: 4696
  • Nacionalidad: ar
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #36 en: Lunes 11 de Julio de 2005, 07:41 »
0
Cita de: "bob esponja"
la primera vez que lei la comparacion de MSDN  con el man la deje pasar, pero esta mal que a los que recien empiezan se los asuste con "el monstruo de linux"
La utilizo muchas veces por la simple razon de que incluso compañeros de trabajo me han llegado a decir que man es mejor que la MSDN.

 :whistling:

Por cierto en el tema sobre Linux dejaste un mensaje bastante largo pero no te vi responder despues, te invito que lo hagas.

Nacional y Popular En mi país la bandera de Eva es inmortal.


Queremos una Argentina socialmente justa, económicamente libre y  políticamente soberana.
¡Perón cumple, Evita dignifica!


La mano invisible del mercado me robo la billetera.

bob esponja

  • Miembro MUY activo
  • ***
  • Mensajes: 411
    • Ver Perfil
    • http://marianoguerra.blogspot.com
Re: Programar La Gpu
« Respuesta #37 en: Miércoles 13 de Julio de 2005, 07:09 »
0
que el man sea mejor que el MSDN es una gran mentira en eso concuerdo con vos

Eternal Idol

  • Moderador
  • ******
  • Mensajes: 4696
  • Nacionalidad: ar
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #38 en: Miércoles 13 de Julio de 2005, 07:38 »
0
Cita de: "bob esponja"
que el man sea mejor que el MSDN es una gran mentira en eso concuerdo con vos
 :ph34r: Menos mal jeje  :comp:

Nacional y Popular En mi país la bandera de Eva es inmortal.


Queremos una Argentina socialmente justa, económicamente libre y  políticamente soberana.
¡Perón cumple, Evita dignifica!


La mano invisible del mercado me robo la billetera.

micropais

  • Miembro activo
  • **
  • Mensajes: 93
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #39 en: Lunes 12 de Diciembre de 2005, 23:08 »
0
Cita de: "CodigoDavid"
Mis dudas son unas "cuantas", y esque, estoy en estas:


(1)Quiero programar directamente el hardware, graficos, teclado, raton, sonido.

{
Estamos en que para hacer esto, de buen principio ni pensarlo de hacerlo bajo, por ejemplo WinXP por que simplemente protege la memoria asignandole una zona virtual de memoria a cada proceso y analizandola a su voluntad para que el proceso no acceda a zonas de memoria de otro proceso(problema numero 1), me direis muy bien, utiliza la API de windows y ya esta, pero yo digo, no esta!! por que no pienso utilizar esa API........no de momento, la solucion mas facil seria programar en entorno MS-DOS, pero tenemos el problema de la barrera de los 640 Kbytes, podria utilizar directamente el hardware y tal con las interrupciones, pero........... y si mi programa que haga ocupa mas de 640 Kbytes en memoria que?, ahy viene una duda/pregunta, aunque todos sabemos que MS-DOS tiene la barrera de los 640 Kbytes, y aun teniendo la memoria extendida su uso es muy limitado, como al fin y al cabo MS-DOS es un programa mas echo en ensamblador, hay alguna manera de poder utilizar toda la memoria disponible en el PC mediante algunas rutinas en ensamblador y tambien extender los 16 bits a 32 bits, superando asi las barreras, es decir, si yo tengo por ejemplo 512MB de memoria RAM fisica en el ordenador, pues poder utilizarlos todos y no 640KB solamente, igualmente el tema de la cantidad de bits, osea que aunque los programas de MS-DOS sean de 16 bits, de alguna manera yo puedo hacer programas corriendo en 32 bits aunque MS-DOS no lo sea mediante el apoyo de algunas rutinas de ensamblador? no pido que me digais como se hace, simplemente pido que alguien me diga si se puede hacer lo que yo he dicho o no, lo demas ya es trabajo mio.........,
}



(2)Programar graficos, pero nada de VGA ni SVGA, sino una GPU(si si, una aceleradora en el AGP)
{
aqui viene mi mayor duda, y es que por internet veo montones de tutoriales del modo 13h, que si VGA, que si SVGA, VESA 1.0 y 2.0, tenemos que:

VGA: 256 colores, caca de la vaca, no me sirve, no me conformo.........
SVGA: otro tanto de lo mismo.....
ESTANDAR VESA: 16 millones de colores y todo lo que tu quieras, pero tampoco me conformo por su lentitud

explicacion de por que no me sirve lo del vesa:

por la profundidad de color si me serviria, pero, imaginaros que tengo que hacer un sistema operativo como el windows, con 32 bits de color, esto es, 16 millones de colores, pero como imaginareis, ni de coña tendra la velocidad que tienen los graficos del windows, por que aunque alguien no lo sepa y aunque lo parezca, windows NO esta echo con vesa, ese sistema accede directamente al hardware, y en ordenadores modernos ya no estamos hablando de VGA ni SVGA si no de GPU o "Graphics Accelerated Unit", o lo que es lo mismo, targetas aceleradoras 3D de alto rendimiento, con procesador propio, algunas que llegan a tener 256MB de memoria de video GDDR3(la mia, una 6800GT........), y ahi viene el problema, veo un monton de paginas de los modos anteriores, pero todavia no he encontrado ninguna que hable de como acceder directamente a ese tipo de hardware, y mis preguntas son, ¿se accede directamente a la aceleradora 3D o tan solo al bus AGP?¿que interrupcion es la encargada del bus AGP o de la targeta aceleradora?¿cuales son las direcciones de memoria?¿que registros tiene el procesador(GPU) propio de la targeta aceleradora?¿alguien sabe el nombre de estos registros? pues eso, alguien sabe "algo" sobre el tema? por que, existir tiene que existir algo por c******, por que los sistemas operativos que existen como windows, no salen de la parrilla como por arte de magia..............................................e inevitablemente deben usar alguna "cosa" para realizar sus cometidos, "algo" que si ellos pueden utilizar programandolo en ensamblador y ese "algo" como por ejemplo una Nvidia GeForce 6800GT 256MB GDDR3 esta en mi ordenador, pues por c****** debo de poder programarlo yo de alguna manera utilizando ensamblador, ¿existe algun libro al respecto a poder ser en castellano?, recuerdo, que nada de APIS ni DirectX ni OpenGL ni nada por el estilo, empezando desde 0(programacion del hardware pura y dura.....)MUCHAS GRACIAS
:comp:

me parece que hay un poco de confusion en el tema.

Si, si se puede programar la VGA y la SVGA, lo que falta es informacion sobre los registros . un driver propio en ASM no suele ocupar mas de de dos mil o tres mil lineas e incluso menos si solo queremos algunos modos graficos.

hay un libro bastante antiguo PC INTERNO 5 que muestra como crearnos nuestros driver graficos tanto en ASM ,C y PASCAL.
el código fuente no suele pasar de cien lineas en asembler para modos graficos en concreto. de todas maneras no profundizan mucho y lo que puedas obtener será de los codigos fuente,que por supuesto están en ingles.

Suelen partir de una idea tan basica como iniciar el modo primitivo mediante el bios , para que este haga el trabajo sucio por ejemplo 640x480 16 colores , y mediante manipulacion de registros propios de VGA pasarlo a 256 colores o mas.
hay quien se atreve desde cero pero para eso se necesita conocer donde se toca -

- Aviso de que te puedes quedar sin monitor al forzar la frecuencia del mismo.
de echo estube practicando bastante con los registros aleatoriamente y fue la primera vez que vi al monitor generar ruidos- curioso- ,no me lo cargé pero duro poco aquel monitor - casualidad?-.

de este mismo modo se crean los tan famosos modos  chain X hasta 320x400x256 colores , tener en cuenta que en el libro no mencionan las SVGA solo las VGA , estos registros tienen que ser compatibles hacia abajo osea que siempre estan ahí.

yo estube practicando con modos 640x400 y 800x600 y 1024x768 pero en estos últimos modos, habia problemas con la visualizacion del raton , al final lo dejé todo porque aunque sigas los ejemplos al pie de la letra hay cambios bastante decepcionates cuando cambiamos de tarjeta grafica, o dicho de otro modo lo que programaste para una ya no vale para otra salvo si vas probando con bastantes numeros para el mismo modo graficos. un ejemplo del libro para 800x600 es ir probando con llamadas bios con varios numeros supuestamente estandar , algo parecido a lo que hace el windows cuando cambia el modo grafico , y te pregunta si lo puedes ver correctamente.

creo que se puede programar los modos graficos partiendo del bios y usar drivers propios , estoy en ello , lo que pasa que en internet y en español no pasan del modo 13h.
parece que internet hay algo de TABU sobre la manipulacion de las SVGA ni el propio google se atreve - ¿SVGA? quizas quiso decir pasar del tema -

Para el resto de las preguntas usa dow4gw dos en modo protegido , el resto de tus dudas es facil de encontrar en internet .
crear un S.O desde cero creo que deberias ver algo de linux que muestran el codigo fuente .

Aun asi es una tarea bastante ardua para una sola persona , y el probema no es saber programar ni el tiempo que haga falta para ello , si no la falta de informacion.

ahi van un par de paginas para "empezar" eso si en ingles, no te pierdas por que hay de todo.
si consiges algo no dudes en comunicarlo .

http://textfiles.tqhosting.com/programming/
http://geocities.yahoo.com.br/conexaopcpc/...os/Hardware.txt

saluDoS  :hola:

micropais

  • Miembro activo
  • **
  • Mensajes: 93
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #40 en: Martes 13 de Diciembre de 2005, 00:49 »
0
Cita de: "Amilius"
Pues felicidades CodigoDavid y recordarte nuevamente que aunque no te guste el inglés es el lenguaje natural defacto del mundo del intercambio de información y si realmente quieres alcanzar tus metas NECESITAS poder leerlo por lo menos.
existen en la actualidad buenas herramientas de traduccion como
Word Magic interpreter profesional , que te ayudaran e incluso aun nivel muy bajo de tu ingles , este en concreto ,HABLA y todo, tanto en ingles como en castellano.
Y según el texto a traducir deberás ayudarle un poco o nada en la seleccion de palabras.

aprender ingles hoy dia es casi basico , si te puedes ayudar con buenas herramientas mejor que mejor.

_____________________________________________

traduccion a groso modo
______________________________________________
 
They exist at the present time.
Good tools.
of translation like Word Magic professional interpreter.
That they help to you and enclosure.
Even very low level of your English.
HE TALKS TO this in concrete and all.
So much in English I have a meal in Spanish.
And according to the text to make a translation.
You will have to help to him a little.
Or swim .
 In the selection of words.

Learning English nowadays.
It is approximately basic.
If you can help oneself.
With good tools.
All the better.


SALUDOS

 :P  :P  :P

Eternal Idol

  • Moderador
  • ******
  • Mensajes: 4696
  • Nacionalidad: ar
    • Ver Perfil
Re: Programar La Gpu
« Respuesta #41 en: Martes 13 de Diciembre de 2005, 08:46 »
0
Cita de: "micropais"
:comp:

me parece que hay un poco de confusion en el tema.

Si, si se puede programar la VGA y la SVGA, lo que falta es informacion sobre los registros . un driver propio en ASM no suele ocupar mas de de dos mil o tres mil lineas e incluso menos si solo queremos algunos modos graficos.
¿Que confusion? Solo para empezar estas respondiendo a una pregunta de hace seis meses y dos pagina atras ...

VGA, SVGA, VESA ya fueron programados por varios de los que participamos en este hilo. Un driver para Windows no se suele hacerse en assembly, es mas, Microsoft jamas lo certificaria.

Nacional y Popular En mi país la bandera de Eva es inmortal.


Queremos una Argentina socialmente justa, económicamente libre y  políticamente soberana.
¡Perón cumple, Evita dignifica!


La mano invisible del mercado me robo la billetera.

mruize85

  • Nuevo Miembro
  • *
  • Mensajes: 2
    • Ver Perfil
Re:Programar La Gpu
« Respuesta #42 en: Jueves 9 de Mayo de 2013, 03:30 »
0
El hecho de que una misma tarjeta gráfica realice la tarea de mostrar las imágenes por pantalla y la de procesar la información 3D no significa que sean cosas relacionadas. Me explico:

Una tarjeta gráfica en si misma está compuesta por un conversor digital a analógico, memoria (framebuffer) y algo de lógica. Su única función es la de dibujar en pantalla el contenido de esa memoria, es decir, la imagen.

Una GPU no es una tarjeta gráfica, sino que es una pieza de hardware diseñada para convertir de forma rápida y eficiente vectores y texturas en un array de píxeles que puede ser mostrado por pantalla o no. De hecho, la GPU de una tarjeta gráfica moderna puede ser usada sin interferir en lo mostrado por pantalla, pues son dos cosas muy distintas.

Es perfectamente posible diseñar dos tarjetas independientes que realicen ambas funciones por separado: una que se encargue de "refrescar" la pantalla y otra que se encargue de convertir esos vectores y texturas en mapas de bits.

Lo que debe quedar claro es que la visualización por pantalla y el dibujado 3D son cosas distintas. Es perfectamente posible implementar la funcionalidad de una GPU en el propio procesador (la CPU); claro que a expensas de una seria reducción del rendimiento. Como curiosidad mencionar que existen "tarjetas gráficas" que no disponen de un conversor analógico digital ni de un conector VGA o DVI cuya única finalidad es la de ofrecer esa "aceleración por hardware", es decir, la GPU para cómputos de propósito general y no solo el rasterizado de imágenes vectoriales en 3D.

Si tu misión es implementar una librería 3D como OpenGL para un sistema operativo que no soporte el fabricante de tu tarjeta, olvídate de acceder directamente al hardware, pues hay muy pocas tarjetas cuyas especificaciones sean abiertas y muchas menos cuyas especificaciones sean completas. Asume que solo podrás acceder a las funciones de tarjeta de vídeo (framebuffer) mediante el estándar VESA y deberás implementar toda la funcionalidad de la librería 3D en el procesador (usando las extensiones SSE mejorarás bastante el rendimiento).

Saludos.