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 <srol...@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 <srol...@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@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= > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
