Texturas Más Eficaces

[Loover]

 ¿¿ Es verdad que para una misma superficie se renderiza más rapido con una textura de 128x128 que con una de 128x32 ??

[Haddd]

 No, al reves, se renderiza más rápido la de 128x32. La razón es que para renderizarla sólo necesita acceder a la memoria 128x32 veces. Sin embargo si la textura es de 128x128 tiene que acceder 128x128 veces.

[Loover]

 Vale eso pensaba, pq es lo lógico. Pero me habían comentado lo contrario y me asaltaba la duda, gracias.

[Zaelsius]

 Lo extraño es que yo leí en unos papers de nVidia(creo..) que las texturas más rápidas son las de 512x512, en "comparación" con otros tamaños. Recomendaban tambien empaquetar varias texturas pequeñas en una de 512x512.

[Ithaqua]

 Haddd, no es tan sencillo. El nº de accesos no es para nada igual al nº de texels.
Depende de muchos factores: del tamaño de la textura, del mapeado, del filtrado, del tamaño del polígono...
Del tamaño de la textura porque a menor tamaño, menor nº de texels pueden ser referenciados (por otra parte más cache hits y menor gasto de ancho de banda). Del mapeado porque no es lo mismo una interpolación (0, 0) a (1, 1) en la que recorres todo el rango que de (0, 0) a (0, 0.1) en la que el rango es más pequeño. Del tamaño del polígono porque cuanto más pequeño, menos datos necesitarás samplear de la textura. Lo mismo con el filtrado, del que depende el nº de muestras tomadas por pixel dibujado.
Y seguro que hay más factores :)

[Haddd]

  Sí, yo no digo que no, pero si es cierto que a mismas condiciones, es más óptimo un 128x32. De hecho, es más rápido utilizar una textura con compresión DTX que sin compresión pq el nº de accesos es menor.

Lo de empaquetar las texturas se refiere a que cuando un motor "selecciona" una textura, el procesador gráfico tiene que "reorganizar" sus variables internas. Por ello te dice que es mejor tenerlo todo en una empaquetado. Pero ahora parece ser que ya la penalización por cambio de textura es pequeña, o por lo menos eso he leido no se donde. :huh:

[Loover]

 Bueno, os voy a poner exactamente cuál es mi duda y así sabiendo el caso en cuestión podreis aconsejarme mejor. Pero yo creo que para este problema está claro que cuanto más peque mejor.
Bueno:

El caso es que para poder renderizar imágenes de cualquier tamaño en una libreria gráfica 2d que estoy haciendo partía la imágen en bloque (de tamaño CUADRADO pero depediendo este del máximo de textura permitido y por supuesto del tamaño de la imagen).

Ahora imaginad una imagen de 513x513: (que putada eh? jajaja  :lol: )
Pues bien la clase que tengo la cortaría en 4 de 512x512. Cuando la de la esquina inferior derecha solo usaría un texel!!!! Jajajaja
Me vasta cambiar un par de lineas para que se corte en una de 512, en dos de 2x512 y 512x2 y otra de 2x2. ¿Porque de dimensión 1x1 se puede?

Este por supuesto sería el caso más desfavorable. Pero vamos, es un caso posible y usando texturas no CUADRADAS gano mucho en este caso, ¿o no?

Pero me comentaron que las texturas rectángulares tenían penalización (aunque el que lo dijo NO estaba seguro).

Pues eso, gracias a todos.

Un saludo

[Loover]

 "Basta" es con B de Burro.

PD: Odio que no se puedan editar los mensajes

[Haddd]

 ¡Olvídate de la penalización de velocidad!

Por cierto, eso de texturas de 2x2, no es standard. Hay una variable que te dice el tamaño mínimo y máximo de las texturas.

Y finalmente, también hay una variable que te dice si puedes utilizar texturas que no sean potencia de 2, que ya hay tarjetas que las utilizan, y es porque con DX9 se utiliza profusamente el RenderTarget y es mucho más ventajoso que pueda tener un tamaño sin restricciones. Creo que mi Radeon 9500 sí soporta texturas no cuadradas.

Yo me preocuparía de optimizar la máximo la memoria de vídeo que eso sí que es optimizar, porque si tiene que ir al AGP a buscar datos....¡te ralentizará una barabaridad!

[Grugnorr]

 Que yo sepa "todas" las tarjetas soportan texturas no cuadradas... no estaréis hablando de texturas de lado potencia de 2?.

[Mars Attacks]

Ahora imaginad una imagen de 513x513: (que putada eh? jajaja  :lol: )

Yo me quedé flipando cuando vi los tamaños de las texturas para el Blade (las que puso el tipet ése porque se enfadó y nosequé). Tenía los formatos más inverosímiles: 1019x536 y cosas así  (uoh)  

[Loover]

 Ajá, vale gracias.
1) Lo que me interesa saber ahora es como obtener para OGL y D3D:

- El mínimo permitido de textura
- Sí se pueden usar texturas de cualquier tamaño

El máximo de textura ya sé obtenerlo

2) Hadd dijo:

Yo me preocuparía de optimizar la máximo la memoria de vídeo que eso sí que es optimizar, porque si tiene que ir al AGP a buscar datos....¡te ralentizará una barabaridad!

¿Cómo se hace eso?

Un saludo

[MA]Mestre]

 

El mínimo permitido de textura

En OGL no he ledio nada nunca de mínimo permitido por textura. Con Mipmapping se llega a hasta generar texturas de 1x1. Así que no creo que haya mínimo.

Sí se pueden usar texturas de cualquier tamaño

En OGL si encuentras la extensión GL_ARB_texture_non_power_of_two del ogl1.5. ( Puede que la tarjeta soporte la extensión, pero si no tienes los drivers actualizados... ...no aparecerá )

2) Hadd dijo...

Cuando habla de formas de optimizar la memoria creo que se refiere básicamente a comprimir texturas, y tener cargadas tan solo las estrictamente necesarias. Pero que se explique el mismo, que me corrija si me equivoco... ;)

Me parece recordar en el Quake2, cuando por entonces 2MB de una Matrox era algo glorioso,  que en la mano del personaje se utilizaban las mismas texturas que en la cara ( o de otro lado), evidentemente mapeadas con habilidad. Eso tb es optimizar la utilización de memoria...  :D

Código [Seleccionar] Expand

Lo extraño es que yo leí en unos papers de nVidia(creo..) que las texturas más rápidas son las de 512x512, en "comparación" con otros tamaños. Recomendaban tambien empaquetar varias texturas pequeñas en una de 512x512.

No me extraña... como las CPU's de intel que estan optimizadas para varaibles integer ( 32bits ). Evidentemente una textura de 512x512 ocupa más espacio en memoria que una de 512x32, pero el rendimiento no tiene que ser mejor, muchos factores intervienen como bien comenta Ithaqua.

Un saludo.

[Mars Attacks]

 Adivina cuántas texturas utiliza el CVRîOS (sin contar las pantallas de inicio)  (twist)  

[Loover]

 Gracias MA]Mestre por los datos. Haciendo recuento entre lo que habeis dicho y lo que he buscado tenemos:

D3D9

Tamaño máximo
D3DCAPS9 Structure > DWORD MaxTextureWidth | DWORD MaxTextureHeight

Tamaño mínimo
No lo encontrado, ¿seguro que hay mínimo Hadd?

Texturas que no sean potencia de 2
D3DPTEXTURECAPS_NONPOW2CONDITIONAL pero super capadas e inútiles para mi caso en particular pues no se le pueden aplicar filtros mipmap:

Conditionally supports the use of 2-D textures with dimensions that are not powers of two. A device that exposes this capability can use such a texture if all of the following requirements are met.
- The texture addressing mode for the texture stage is set to D3DTADDRESS_CLAMP.
- Texture wrapping for the texture stage is disabled (D3DRS_WRAPn set to 0).
- Mipmapping is not in use (use magnification filter only).
- Texture formats must not be DXT1-5.
A texture that is not a power of two cannot be set at a stage that will be read based on a shader computation (such as the bem, beml, or texm3x3 instructions in pixel shaders versions 1_0 to 1_3). For example, these textures can be used to store bumps that will be fed into texture reads, but not the environment maps that are used in texbem, texbeml, or texm3x3spec. This means that a texture with dimensions that are not powers of two cannot be addressed or sampled using texture coordinates computed within the shader. This type of operation is known as a dependent read and cannot be performed on these types of textures.

OGL

Tamaño máximo

glGetIntegerv (GL_MAX_TEXTURE_SIZE, &mInfo.mMaxTextureSize);

Tamaño mínimo

No tiene (1x1)

Texturas que no sean potencia de 2

GL_ARB_texture_non_power_of_two del ogl1.5.

Muy buenas, si admiten mipmap y cumplen más requisitos que las de D3D9:

   

Conventional OpenGL texturing is limited to images with power-of-two
    dimensions and an optional 1-texel border.  ARB_texture_non_power_of_two
    extension relaxes the size restrictions for the 1D, 2D, cube map, and 3D
    texture targets.

    There is no additional procedural or enumerant api introduced by this extension
    except that an implementation which exports the extension string will
    allow an application to pass in texture dimensions for the
    1D, 2D, cube map, and 3D targets that may or may not be a power of two.

    An implementation which supports relaxing traditional GL's power-of-two size
    restrictions across all texture targets will export the extension string:
     "ARB_texture_non_power_of_two".

    When this extension is supported, mipmapping, automatic mipmap
    generation, and all the conventional wrap modes are supported for
    non-power-of-two textures