[Mesa-dev] ARB_texture_buffer_range offsets

[Roland Scheidegger]

But even dword offsets aren't translatable right now to
pipe_sampler_view first_elements if the format has more than 32 bits.

Roland

Am 06.11.2014 um 18:21 schrieb 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=
>>