[Mesa-dev] ARB_texture_buffer_range offsets

[Marek Olšák]

I'd say it's a spec bug. ARB_texture_buffer_range should say that the
offset should be a multiple of an element size, but it doesn't. The
question is, what should the element size be? One component or the
whole pixel?

Marek

On Wed, Nov 5, 2014 at 9:08 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev