[Mesa-dev] ARB_texture_buffer_range offsets

[Marek Olšák]

For radeonsi, I think only x8, x8y8, and x16 fetches can be
byte-aligned. Everything else is dword-aligned (the 2 lowest bits are
ignored). I guess the cap should be 4 then.

Marek

On Thu, Nov 6, 2014 at 4:55 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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=
>