Texture Compression

[Pickle]

Based on the GLESv1 extensions there does not appear to be any support for texture compression for RGBA textures. I would hope that something would come about given that this is SOC with the expectation of a low amount of memory being available.
Could someone from Broadcom confirm that Broadcom is or is not intending to provide any support?

Also using the memory slice configs the lowest option with 32 mb dedicated to the GPU results in an EGL error for a bad alloc. I am using hdmi at 1080p resolution.

[jackokring]

So that's about 4MB for the framebuffer, and another 4MB for the surface open 32bit RGBA. I think the Pi is 16bpp, so maybe not quite. Then there is all the vertex data, and the textures. Have you tried 16bpp textures, or using a texture organizational hierarchy? The hardware could map many textures onto the one quad, using various blend modes and stencil masking (a non alpha blend).

Can you not render to a smaller surface, and then use this surface as a texture for a one square scene at the larger resolution? Using a spline interpolate, after an edge sharpen kernel,or a more impressive less computational effect. You'll also get 4* polygon render at half resolution, and the full resolution post scale filter is constant time. If this time is less than 3/4 of your polygon render time allocation, then you get more polygons per second.

Cheers Jacko

[jackokring]

Could yo not just draw a scene of uninteresting coloured objects and project it onto a buffer, as a texture, and then map this texture onto your actual scene? This turns textures into vertex lists....

Cheers Jacko

p.s. say thank you

[jackokring]

If you also switch off the lighting off in the shader used for rebuilding textures, so as to render at constant colour, or pick a different shader mathematics and use distance and angle to select colour... What happens when you wiggle the texture render?

Cheers Jacko

[jackokring]

I wonder if there is anything on the internet about FIF file compression, and affine mapping.

[jackokring]

Try activating dithering in the shader (and not doing edge detect), this has little real cost (could be very computationally expensive, but there are simple effective approximations), and reduce the resolution of polygon rendering. The dithering will help with fine detail approximation when the image is fully scaled, and if a mild Gaussian blur is then applied, apart from minor grainy-ness to the image, the effect will be quality high res.

If you don't like the grainy-ness, then invest $200 in a PCIe graphics card for a PC, and all the other things it needs. Or perhaps run this technique on a bigger system, with 32bpp, and use the extra render for spectacular effects and super moving shadow and moving lighting.

Cheers Jacko

[Paeryn]

Based on the GLESv1 extensions there does not appear to be any support for texture compression for RGBA textures. I would hope that something would come about given that this is SOC with the expectation of a low amount of memory being available.

It says it supports GL_OES_compressed_paletted_texture, they can be in RGBA format.

[Pickle]

Hey Paeryn good to see familiar faces.

I didnt think that would work for RGBA, but I will now look into it. Thanks

[Paeryn]

I've just ran a quick test and it looks like paletted textures aren't supported by the hardware, rather the driver just expands the data to full RGBA8.
My test allocated 21 512x512 RGBA8 (1MB) textures before running out of memory, when doing the same with PALETTE8_RGB8 it also stopped at 21, plus took longer to upload each texture which would account for the conversion.

This gives approx 21MB of texture ram on the 192/64 split. Using the 128/128 it goes up to 68MB - only 47MB more. This is with a 1280x720 framebuffer.

[lb]

For the love of all that is good, please use OpenGL ES 2.0. ETC1 compression is supported.

Edit: sorry, I did not notice you want compressed RGBA textures. ETC1 does not support alpha. But you can use an ETC1 compressed RGB8 texture and store alpha in a separate A8 texture. It's easy to combine both textures in the fragment shader, and with 12 bits per pixel you're still quite memory efficient. If you can get away with it, store the alpha with halved resolution and save even more bits.

[Pickle]

paeryn are you letting the driver do the compression or do you know of a tool that can compress to the palette format? Thanks for doing the checks.

lb : for the moment the code base is 1.X based. Maybe when i have the time I will create a 2.0 renderer.

[jackokring]

I think I get it now. All the lights have to be summed as a 'varying' in the vertex shader...
Dither could be done by adding a texture of randomness to this light...
A half shader rate if/else could do main scene, and projected texture(s)... or does this need a texture to work as the frame output when, the auto generated texture is being made for later use in the main scene generation?
And the texture co-ordinate has to be used for deciding which motion matrix to apply... in the vertex shader? Or does active program motions between relative objects have to be CPU controlled?
No dynamic variable indexes, no return statements in if/else... blah...

Anywhere close?
Jacko

[Pickle]

Jacko, post a realistic message or the next one gets you flagged as spam, as i suspect you are.

[Paeryn]

Pickle, you have to provide the data in palette form, but as I put earlier it looks like the driver expands it back into full 32bit RGBA8 when uploading it into the the gpu's texture space.
The format gl expects is 256 32bit RGBA palette entries followed by width*height 8bit index entries.
There are plenty of image converters that can convert files for you e.g. xnconvert. .bmp is the nearest file format to what gl expects the data to be in, you'll just need to swap the red & blue components in thecolourmap as .bmp is BGRA. Pass the start of the colourmap as the data to glCompressedTexImage2D. Note: 54 is the size of the header that xnconvert writes and could be different for other programs.

Code: Select all

// bmpfile is where .bmp is loaded to, 54 is offset to start of colourmap
char *buff = bmpfile + 54; 
for (int i=0; i<256; i++) {
  char b = buff[0], r = buff[2];
  buff[0] = r;
  buff[2] = b;
  buff +=4;
}
glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_PALETTE8_RGBA8_OES,
	width, height, 0, width*height + 256*4, bmpfile+54);

[Pickle]

Paeryn, thanks for the information. I also found the same answer here just a minute ago:
http://www.khronos.org/message_boards/v ... f=4&t=1382

But too bad about the feature not actually being of any use.

[blu]

Paeryn, thanks for the information. I also found the same answer here just a minute ago:
http://www.khronos.org/message_boards/v ... f=4&t=1382

But too bad about the feature not actually being of any use.

I know it's not much of a consolation, but most modern silicon "supports" paletted textures in the exact same manner. I guess the reason is, it'd be a waste of transistors to do something which can be done trivially in a shader *wink-wink*

ps: Hi Pickle ; )

[Pickle]

Hi blu glad to see you around.

I am thinking that I may try 128/128 and add some swap and see how it goes.
I may be able to store some images as RGB, and then use ETC1 if i write 2.0 renderer.
Or I can give up on the rpi for this project.

I was having similar issues with the pandora, but pvrtc worked out rather well. Too bad rpi didnt have better support for texture compression. Or they could have gone for 512 mb.

[blu]

The thing is, with shaders you can stick with paletted RGBA if you really deem those important - the whole palette thing is just a 'dependent texture read' look-up op. You can do it in different manners too: with some address math and one TMU, or with no math and two TMUs. The latter is absolutely straight forward: you put your palette in TMU1 (as a 256x1 texture) and you put your paletted image in TMU2, then your texel fetch is a texture2D(tmu1, vec2(texture2D(tmu2, coords).x, .5)). Voila (at no filtering, of course).

[Pickle]

well the palette textures only came up as a method for texture compression that is "supported" by BCM in order to meet GLES 1.X specs,
So im not sold on them, and if I went with a programmable renderer I would need to see what all the options are (though it seems to be very few)

I was thinking the ETC1 with RGB only would not work well. In this project there are mainly 2 textures types. A group with alpha and another set with colorkeying. In order to make it support the colorkeyed images I convert the colorkey into alpha.
In order to use the RGB the image would need to cover the entire size of the image, and there are just not enough of those.

Im also converting NPOT images to POT, so theres some waste there.
But im also shrinking some images resolutions by half.

One other I havnt been too sure on is when using glTexImage does the type matter for the final internal structure? I assume it is not since the internal format will be GL_RGBA, so i expect the type is only used to convert each pixel to the full RGBA.

[Paeryn]

One other I haven't been too sure on is when using glTexImage does the type matter for the final internal structure? I assume it is not since the internal format will be GL_RGBA, so i expect the type is only used to convert each pixel to the full RGBA.

You're right, the type is used by the driver to convert the data you pass into the internal_format. This is then expanded to the full RGBA by the texture unit when sampled.
By my quick test method from above, for texture size of 512x512:
GL_ALPHA or GL_LUMINANCE gives 82 textures,
GL_LUMINANCE_ALPHA gives 41,
GL_RGB & GL_RGBA both give 20.

[blu]

well the palette textures only came up as a method for texture compression that is "supported" by BCM in order to meet GLES 1.X specs,
So im not sold on them, and if I went with a programmable renderer I would need to see what all the options are (though it seems to be very few)

I was thinking the ETC1 with RGB only would not work well. In this project there are mainly 2 textures types. A group with alpha and another set with colorkeying. In order to make it support the colorkeyed images I convert the colorkey into alpha.
In order to use the RGB the image would need to cover the entire size of the image, and there are just not enough of those.

Well, if you're not set on paletted textures then I'd echo what was already suggested earlier - go with etc1 for the RGB and keep the alpha in a separate 8bpp texture. That also gives you the advantage that you can decouple the color res from the alpha res.

Im also converting NPOT images to POT, so theres some waste there.
But im also shrinking some images resolutions by half.

VC IV does NPOT, you can use that if the code would not need much of a fixup.

One other I havnt been too sure on is when using glTexImage does the type matter for the final internal structure? I assume it is not since the internal format will be GL_RGBA, so i expect the type is only used to convert each pixel to the full RGBA.

Well, yes and no.

Yes, in the sense that generally you're correct, in the traditional desktop GL there are plethora of seamless conversions that could facilitate the transformation from the input format & type to the internal format. With GLES, though, things are a tad different - conversions are minimized, so the internal format is normally expected to match the input format, on-the-fly-compression & paletted textures non-withstanding. The general rule of thumb is, the stack with try to select an internal format which both meets the base internal format you've specified (RGBA, RGB, etc), and matches the precision of the input type, which given the few formats the core standard supports, is not so hard. So, an RGB565 input type will likely end up as RGB565 internal format, quite possibly without even as much as a swizzle during the actual internal storing. The conversion to 'full RGBA' you're referring to may not happen at the stage of internal storage, but as late as during actual texel fetching, where it all goes to fp anyway.

[Paeryn]

So, an RGB565 input type will likely end up as RGB565 internal format, quite possibly without even as much as a swizzle during the actual internal storing. The conversion to 'full RGBA' you're referring to may not happen at the stage of internal storage, but as late as during actual texel fetching, where it all goes to fp anyway.

Forgot to check that part. The 16bit RGB[A] formats do indeed stay 16bit in texture memory and are expanded when sampled.
It looks like the only time a conversion could be being done is for a format of GL_RGB and type GL_UNSIGNED_BYTE - and that would be to add an implicit ALPHA byte of 255 (RGB takes the same amount of texture memory as RGBA in this case).
The driver gives an error if you try passing a type that doesn't fit the internal_format. So you can't have a format of GL_RGB and a type of GL_UNSIGNED_SHORT_5_5_5_1.

[Pickle]

I think that switching from full 32 bpp to 16 bpp (GL_UNSIGNED_SHORT_5_5_5_1) . This would work for most of the images. Some may have half alpha, which GL_UNSIGNED_SHORT_4_4_4_4 could work for. In both cases I could be cutting my size in half, if the hw indeed does retain the data format.

[lb]

Well, the 4444 format has quite horrible quality... I cannot recommend it at all. What's your use-case?

[hexameron]

Well, the 4444 format has quite horrible quality... I cannot recommend it at all.

+1 on that. Broadcom will have to support ETC2 compression for GLES 3.0 on their next-gen Videocore chipsets, so if we ask nicely they might backport it to the pi.