Yo creo que la razón fué para dar estabilidad y evitar errores "humanos". Es decir, OpenGL necesita una copia en RAM, ya que casi nunca caben todas las texturas en VRAM al mismo tiempo, por eso el driver se encarga de subir y bajar lo que sea necesario. Con la copia interna, se evitan errores como por ejemplo, que el usuario borre el buffer de la textura mientras se está usando.

Si no vas a modificar la textura, puedes eliminar tu copia (la 1), así liberas RAM.

Las pruebas:

Apple añadió una extensión para poder mantener la copia del usuario como copia de memoria de sistema manejada por OpenGL, para así ahorrarse el duplicado http://www.opengl.org/registry/specs/APPLE/client_storage.txt (En el "Overview" está explicado muy claro). El problema es que esta estensión no es muy común en windows, al menos mis drivers ATI no la soportan.

saludos!

[mueve]

Hola marcode,

Lo que hace OpenGL es una copia en memoria de sistema (2), y luego una copia en VRAM cuando se necesita (3), descargandola cuando no. Funciona como dices, excepto que no "mueve" la textura a VRAM, sino que copia la textura a VRAM cuando es necesario. Esto significa que la copia interna de OpenGL en memoria de sistema (la 2) siempre está ahí. Este comportamiento es igual que cuando se crea una textura en DX con D3DPOOL_MANAGED.

saludos!

Tengo un iMac con una ATI Mobility Radeon X1600 de 128 MB, no es la bomba, pero es bastante buena... creo :)

Si tienes Windows, podrás ver mi programa "en directo" en este ejemplo: http://www.devalvr.com/paginas/soporte/compass.html (mi programa es un visor 3D en forma de plugin para el navegador)

Olvidando la textura en el HD, una vez que la cargamos en la aplicación OpenGL, tenemos 3 copias de la textura:

1- En memoria de CPU (la que nosotros reservamos y manejamos)
2- En memoria de CPU (creada por glTexImage2D y manejada por OpenGL, sin acceso directo)
3- En memoria de GPU (creada por glTexImage2D y manejada por OpenGL, sin acceso directo)

Mi pregunta inicial era como acceder a la memoria 2, para poder eliminar mi copia 1. Pero ahora lo que hago es eliminar la 2 y 3 de las partes que no entran en el frustum y listo. Ya probaré con tarjetas más antiguas a ver como va. De todas formas trabajo descomponiendo la textura en trozos de 256x256, esto son solo 200KB, así que puede ser que las transferencias de memoria se hagan muy escalonadas, con lo cual no veo retrasos aunque mueva la cámara muy rápido. Por ejemplo, una textura de 10000x5000 la divido en 750 cachitos.

saludos!

Hola Prompt,

Lo hago tal y como dices. A lo que me refiero con 2 copias es a que OpenGL no solo hace una copia de la textura en VRAM, sino que además hace otra copia en memoria de sistema. Con lo cual tienes dos copias de la misma textura en memoria de sistema, una la tuya, y otra la de OpenGL. Esto no es preocupante en la mayoria de aplicaciones, pero si tienes que cargar una textura de 400 MB, resulta que necesitas 800MB de ram.

Al final he encontrado una solución, aunque no sé si funcionará igual con todos los drivers OpenGL, tengo que hacer más pruebas. Lo que hago es directamente eliminar con glDeleteTextures los trozos de textura que no están dentro del frustum. Luego si entran dentro de la escena las vuelvo a crear con glTexImage2D. Nunca pensé que esto de andar creando y eliminando texturas fuera tan rápido, pero no tengo ninguna penalización en los FPS. Ahora cargando una textura de 350MB la aplicación me consume unos 420MB en vez de 700MB con toda la textura cargada en OpenGL.

Gracias por la respuestas!
saludos

Creo que al final tendré que dejar las dos copias, al menos mientras dure la carga/actualización de las texturas.

Muchas gracias por las respuestas!

[normally]

O_o! Eso se puede hacer en DX?!

Sí, se puede hacer. En DX, si creas las texturas con D3DPOOL_MANAGED, todo el trabajo lo hace el driver, así que te olvidas de las transacciones MEMSISTEMA<->MEMVIDEO. Sin embargo yo tenia muchos problemas de rendimiento, por ejemplo cuando tenia que cargar 200MB de texturas con una tarjeta de solo 64MB de video, así que tuve que hacerlo "a mano". Es decir, creo las texturas con D3DPOOL_SYSTEMMEM, y luego sus gemelas en VRAM con D3DPOOL_DEFAULT sólo si están dentro del frustum. Tambien modifico las texturas dinamicamente (carga de imagen mientras se usa la textura) y las actualizo en VRAM con UpdateTexture. Las transacciones se manejan por hardware, así que no hay problema de rendimiento.

Podeis ver un ejemplo de esto instalando mi plugin (solo windows) y luego viendo esto http://www.devalvr.com/paginas/soporte/compass.html . Este ejemplo crea las texturas en DX y luego las va actualizando a medida que se descarga el Jpeg de 12000x1648. Para hacer esto con OpenGL necesito tener dos copias de la textura en memoria de sistema, la mia que me sirve para actualizar la textura y la que hace OpenGL. Al menos todos los ejemplos que he visto de texturas dinámicas mantienen una copia aparte de la de OpenGL. El problema es cuando cargas una imagen de 20000x10000, en ese momento mantener dos copias es un poco bestial.

Todo seria más sencillo si tuviera acceso al puntero que usa OpenGL en memoria de sistema. O si pudiera decidir, como en DX, donde se crean las texturas. Como dice Pogacha, en la documentacion de OpenGL dice que "GL implementations normally maintain a copy of texture image data", o sea que en la mayoria de los casos tendré dos copias en RAM de lo mismo.

Se agradece qualquier idea  :wink:

Hola,

Estoy convirtiendo mis funciones DX a OpenGL y hay algunas cosas que no consigo hacer igual, por ejemplo, tener los buffers de la textura en memoria de sistema y memoria de video separados.

Solo he encontrado la extensión GL_APPLE_client_storage, que permite crear la textura manteniendo la copia original en memoria de sistema, con lo cual el driver OpenGL solo crea una copia en memoria de video. El problema es que esta extensión no es soportada por todos los drivers, incluso las tarjetas modernas.

Entonces, creando la textura de la forma habitual con glTexImage2D, ¿es posible obtener el puntero de memoria de sistema de la textura en OpenGL? Esto me posibilitaria modificar la textura en memoria de sistema, sin tener que tener dos copias (la mia y la de OpenGL)

saludos!

En España deberia estar prohibido hacer la carrera de informatica, ya que luego no hay ningun sitio donde te compensen por todo el tiempo que has estado estudiando.

En Dublin a mi novia le pagaban 2000€ al mes (desde el primer dia y como base, sin contar horas extra) por trabajar en un McDonals. A ver que titulado cobra esto en su primer trabajo aquí. Cuando cuentas esto, te dicen que la vida está más cara en Irlanda, como si aquí se pagaran 0.80 por un café... :?

saludos!

mierda, no me ha tocado la loteria :(

Felices fiestas y prosperos juegos!!!  :)

Sí, muy interesante.

Hombre, podria ser, pero no hay suficiente base de desarrolladores como para poder vivir del soporte. Mi proyecto es más parecido al shareware, es decir, un programador de shareware no se tira X años currandose un programa para luego liberarlo. Cada proyecto es diferente, según como se ha desarrollado, con qué recursos, que nivel de audiencia, etc., por eso existe el shareware, el freeware, el software comercial, el open source... Ni todo puede ser de pago, ni todo puede ser open source.

En mi caso, debe ser freeware para permitir que se extienda, lo cual me beneficia a mi y beneficia a los desarrolladores (fotógrafos y webmasters)que lo usan, pero hay que sacarle algún beneficio aunque sea de forma indirecta, para poder seguir en la brecha.

Hola!

Desde hace mucho tiempo estoy desarrollando un plugin para el navegador para la visualización de fotografias panorámicas. El plugin es freeware para los desarrolladores (por supuesto tambien para cualquier usuario).
Estaba pensando en poner publicidad en el instalador del plugin, por medio de un banner o algo parecido. He visto que algunos programas ya lo hacen, por ejemplo QuickTime te muestra un anuncio de iTunes al final de la instalación. Ahora mismo hay unas 90000 descargas del plugin al mes. No sé si es buena idea, todavia no he mirado posibles clientes y no sé si habrá alguien interesado.
Me gustaría saber como está el tema, ¿hay alguien que haya metido publicidad en juegos shareware?, ¿sobre qué cifras nos movemos con ese nivel de audiencia?, ¿Cuanto vale un banner en una pagina con 100000 visitantes unicos al mes? ¿Cuanto vale el banner que hay en el foro de stratos?  :)

Cualquier comentario es bien recibido.
saludos!

[en el mismo proceso]

Hasta lo que yo sé (corregidme si me equivoco), una dll solo son datos, datos ejecutables, pero datos al fin y al cabo. Es decir, un proceso (exe) carga la dll y utiliza la clase singleton, después otro proceso carga la misma dll y utiliza la clase singleton. Los dos procesos son independientes y no tienen ninguna manera de comunicarse entre sí a través del código contenido en la dll, ya que la dll son datos que se cargan y se ejecutan en procesos separados.

Nunca he utilizado ni entendido un singleton. Creo que es una clase que solo se puede instanciar una vez, pero en el mismo proceso.

saludos!

Hola Jare,

Perdón por la tardanza en contestar, parece que la notificación de respuesta no me llegó al correo (quizás al spam) y pensé que este hilo se habia quedado sin contestar.

!Muchas gracias por la info! :)  Es exactamente lo que andaba buscando, voy a cambiar mis viejas funciones de mensajes por este WM_COPYDATA que parece que se inventó exactamente para eso.

saludos!