[Mesa-dev] ARB_texture_buffer_range offsets

[Roland Scheidegger]

Am 06.11.2014 um 16:15 schrieb 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?
Imho whole pixel (for block compressed that would be full block, for
things like packed 565 too but neither are possible in GL), i.e. "format
granularity". That said, the whole alignment thing is problematic for
rgb32 (and the possiblity of that was added later,
ARB_texture_buffer_object_rgb32), so maybe it's things like that why the
offset can be just byte aligned (in other words, I'm not convinced it's
just a spec bug, d3d10 doesn't have that problem with alignment).

Roland


> 
> 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
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=Ds_jdCUhL1dGXrkeea1fzl6_iInrZFJOSltaM6dlF9w&s=BNwWkIpsz9GFgPRoMLDU8tEVUPzmIxKINN3Uu9evnXs&e=