Archives Discussions

[laobrasuca]

trying to use glsl, but without this extension i can't make it

Hi all,

well, i've got the hd5770 with catalys 10.8 (from the driver download section) and when carring the gl_extensions i could see that GL_arb_texture_buffer_object_rgb32 is missing. I'm creating an vertex shader to carry 3 components vertices and triangle indices, but since this extension is not supported i just can't make it, it still behave as an 4 components texture, even if i use GL_RGB32F/GL_RGB32UI in the texture buffer. As a matter of fact, the glsl builder give me an warning saying that this extension is not supported. I'm using GLEW 1.5.5 as for wrapping the openGL functions (i'm on windows vista 64bits os), and GLEW does have GL_ARB_texture_buffer_object_rgb32 but not the GL_EXT_texture_buffer_object_rgb32 which is present in the extention list of the card! There exist any way i can have either GL_ARB_texture_buffer_object_rgb32 or GL_EXT_texture_buffer_object_rgb32 enabled in my shader? Otherwise, i can't create my shader at all 😕

thx for your attention and help.

[pboudier]

hi,

the name of the extension should have been ARB instead of EXT (typo which we will fix)

about your GLSL shader, I don't think that you need to have any change regardless of the internal format of the texture buffer. you just need to use the samplerBuffer type and appropriate texelFetch function.

Pierre B.

[laobrasuca]

hi Pierre, thx for your reply. when will you be able to publish a new driver with the fix?

as for the shader, i agree that it won't change. Since as for now the cache line on amd and nvidia's cards is of 128 bits, the cost of retreiving 3 of 4 32bits numbers will be the same, that's maybe the reason why glsl does not provide texelfetch for vec3 types, only for vec4. However, a fetch function for a general buffer name (target) would avoid me to rebind my GL_ARRAY_BUFFER (for vertices and normals) and GL_ELEMENT_ARRAY_BUFFER (for indices) buffers to GL_TEXTURE_BUFFER every time i need to make a fecth inside the shader.

leo

[pboudier]

in terms of performance, this is probably even more complex than what you describe.

the cache line size does have an impact, but if your 96 bits is not aligned to the same offset as a typical 128bits, then you will have to cross two cache lines.

overall, 96bits fetch performance should be lower on hd5xxx than 128bits; so it is really interesting because you can either save memory, or save some special copy operation to convert 96bits data into a more efficient format.

it usually takes 2-3 months before a fix makes it into a public release; if you want to have faster access, you should contact our ISV team who can provide special beta builds.

Pierre B.

[laobrasuca]

Originally posted by: pboudier in terms of performance, this is probably even more complex than what you describe.

the cache line size does have an impact, but if your 96 bits is not aligned to the same offset as a typical 128bits, then you will have to cross two cache lines.

overall, 96bits fetch performance should be lower on hd5xxx than 128bits; so it is really interesting because you can either save memory, or save some special copy operation to convert 96bits data into a more efficient format.

yes, you are rigth, i was too fast on saying that it would be the same. It is a fact that the vec3 fetch will produce offsets, harming performance. But at the same time, introducing a 4th component to keep alignement requires 33% additional memory space. So it is quite a dilemma, unless real 96bits alignement is provided, but this maybe requires quite a lot of changes in hardware. Will the hd6000 series give more support to vec3 (either on glsl or opencl), for a real 96bits alignment?

it usually takes 2-3 months before a fix makes it into a public release; if you want to have faster access, you should contact our ISV team who can provide special beta builds.

ok then, i'll do so.

thx for your time

leo

[pboudier]

So it is quite a dilemma, unless real 96bits alignement is provided, but this maybe requires quite a lot of changes in hardware. Will the hd6000 series give more support to vec3 (either on glsl or opencl), for a real 96bits alignment

the HW does support 96bit alignment natively, but there is a perf penalty. if that format becomes widely used, then we would consider spending area to make this format goes faster, but this is always a tradeoff:

- making this format goes faster makes the texture unit larger

- so we have less of them

- so overall we might lose performance in general

imho, this format makes lots of sense if you really have to keep your memory consumption low to fit in the card: paging in/out will cost much more than having a lower perf on this fetch.

Pierre B.

[laobrasuca]

hi pierre, thx for your time. it's quite curious why GLSL texelfetch supports vec3 alignment for only a few months now while the existing hardware already does so. but it does'nt seem to be a big deal, since not many people manipulate vec3 data type (at least not with fetches into buffers). in my case, i'm kind forced to, otherwise i would end up with additional vec4 fecths in order to simulate vec3 alignment.

about the catalyst 10.9 released a few days now, it still has the same problem with the extension.

thx again,

leo