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 <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
