• Miércoles 24 de Abril de 2024, 01:48

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - mruize85

Páginas: [1]
1
ASM (Ensamblador) / Re:Programar La Gpu
« en: Jueves 9 de Mayo de 2013, 03:30 »
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.

2
C/C++ / Heap de Windows
« en: Jueves 9 de Mayo de 2013, 03:01 »
Tengo unas cuantas preguntas sobre el "heap" de Windows:

¿Tiene el heapde Windows algún formato (pe. para mantener constancia de la memoria libre y usada) o puede ser usada como un array continuo? Es decir, ¿puedo usar la memoria no reservada entre dos bloques reservados sin riesgo a comprometer la integridad del heap?

¿Las funciones de la API de Windows (kernel32.dll, user32.dll...) usan el heap o su uso es exclusivo del código específico de la aplicación?

Necesito una región de memoria de tamaño variable que se comporte como un array que crece por el final. Solo mi aplicación debe acceder a ella y debe existir una forma simple de aumentar su tamaño. Algo similar al heap de Linux y la llamada al sistema brk.

De entrada me planteo usar el heap por defecto que reserva Windows al cargar mi aplicación, pero si no puede ser utilizado como un array continuo de memoria sin riesgo a comprometer estructuras de datos del API de Windows descartaré esta posibilidad.

En caso de que las respuestas a las dos preguntas anteriores sean favorables a mi propósito, ¿es una práctica recomendable o mejor reservo directamente otra región con Virtualalloc?

Gracias.

Páginas: [1]