Trying to fix some bug due to alignment issues in llvmpipe's vertex fetch, I came across some issue with ARB_texture_buffer_range. Namely, it looks like the offsets specified there are always in bytes, regardless the actual format (hence, as long as the TEXTURE_BUFFER_OFFSET_ALIGNMENT is 1, it would be allowed to have an offset of 15 bytes for a rgba32f format for instance making all fetches quite unaligned). However in gallium we actually have first_elem and last_elem parameters in the sampler views which are specified in number of elements (so takes the format into account), which is what d3d10 does and the state tracker translates to that apparently. IMHO d3d10 makes way more sense there because that way the necessary alignment scales automatically depending on the format (so, if the format is 2x16bit for instance you'd need 4 byte alignment for the offset, and only need 16 bytes alignment for 4x32bit, ensuring all lookups are always aligned). This means that 15 byte offset in the example above is completely untranslatable. But if I see that right, OpenGL doesn't work like that, meaning effectively gallium drivers (and I doubt most other drivers neither) cannot actually claim to support TEXTURE_BUFFER_OFFSET_ALIGNMENT lower than 16, even if they'd only need that for 4x32bit formats. Though most gallium drivers indeed claim 1 right now. Looks quite messy...
Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
