On 12.02.2010 18:28, José Fonseca wrote: > On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote: >> On 12.02.2010 14:44, michal wrote: >>> Keith Whitwell wrote on 2010-02-12 14:28: >>>> On Fri, 2010-02-12 at 05:09 -0800, michal wrote: >>>> >>>>> Keith Whitwell wrote on 2010-02-12 13:39: >>>>> >>>>>> On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote: >>>>>> >>>>>> >>>>>>> Module: Mesa >>>>>>> Branch: master >>>>>>> Commit: aa0b671422880b99dc178d43d1e4e1a3f766bf7f >>>>>>> URL: >>>>>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=aa0b671422880b99dc178d43d1e4e1a3f766bf7f >>>>>>> >>>>>>> Author: Michal Krol <mic...@vmware.com> >>>>>>> Date: Fri Feb 12 13:32:35 2010 +0100 >>>>>>> >>>>>>> util: Fix descriptors for R32_FLOAT and R32G32_FLOAT formats. >>>>>>> >>>>>>> >>>>>> Michal, >>>>>> >>>>>> Is this more like two different users expecting two different results in >>>>>> those unused columns? >>>>>> >>>>>> In particular, we definitely require the missing elements to be extended >>>>>> to (0,0,0,1) when fetching vertex data, and probably also in OpenGL >>>>>> texture sampling (if we supported these formats for that). >>>>>> >>>>>> >>>>>> >>>>> Gallium should follow D3D rules, so I've been following D3D here. Also, >>>>> util_unpack_color_ub() in u_pack_color.h already sets the remaining >>>>> fields to 0xff. >>>>> >>>>> Note that D3D doesn't have the problem with expanding vertex attribute >>>>> data since you can't have X or XY vertex positions, only XYZ (with W >>>>> extended to 1 as in GL) and XYZW. >>>>> >>>> But surely D3D permits two-component texture coordinates, which would be >>>> PIPE_FORMAT_R32G32_FLOAT, and expanded as (r,g,0,1)... >>>> >>>> >>>>>> Brian added a table of differences between GL and other APIs recently to >>>>>> gallium/docs - does your change agree with that? >>>>>> >>>>>> >>>>>> >>>>> Where's that exactly, I can't find it? >>>>> >>>> It seems like we'd want to be able to support both usages - the >>>> alternative in texture sampling would be forcing the state tracker to >>>> generate varients of the shader when 2-component textures are bound. I >>>> would say that's an unreasonable requirement on the state tracker. >>>> >>>> It seems like in GL would want (0,0,0,1) expansion everywhere, but D3D >>>> would want differing expansions in different parts of the pipeline. >>>> That indicates a single flag in the context somewhere isn't sufficient >>>> to choose between the two. >>>> >>>> Maybe there need to be two versions of these PIPE_FORMAT_ enums to >>>> capture the different values in the missing components? >>>> >>>> EG: >>>> >>>> PIPE_FORMAT_R32G32_0001_FLOAT >>>> PIPE_FORMAT_R32G32_1111_FLOAT >>>> >>>> ? or something along those lines?? >>>> >>>> >>> You are right. >>> >>> Alternatively, follow the more sane API (GL apparently), assume 0001 as >>> default and use the 1111 infix to override. >> Note it's not just GL. D3D10 uses same expansion. Only D3D9 is >> different. Well for texture sampling anyway, I don't know what d3d does >> for vertex formats. >> >> Though for most hardware it would make sense to have only one format per >> different expansion, and use some swizzling parameter for sampling, >> because that's actually how the hardware works. But not all drivers will >> be able to do this, unfortunately. > > You mean, having a swizzle in pipe_sampler_state ? > > It sounds a good idea. > > In the worst case some component will inevitably need to make shader > variants with different swizzles. In this case it probably makes sense > to be the pipe driver -- it's a tiny shader variation which could be > done without recompiling the whole shader, but if the state tracker does > it then the pipe driver will always have to recompile. > > In the best case it is handled by the hardware's texture sampling unit. > > It's in theory similar to baking the swizzle in the format as Keith > suggested, but cleaner IMHO. The question is whether it makes sense to > have full xwyz01 swizzles, or just 01 swizzles.
Well, this ties into the discussion we had a while ago about the different interpretation of depth textures (luminance/alpha/intensity) in OGL. My vision was something along the lines of ditching all luminance/alpha etc. (and formats with different rgba ordering) formats, much like dx10 does and only have the r/rg/rgb/rgba ones. Then the sampler swizzling determines how it's interpreted. That would solve depth texture problems and avoid the need for two formats here. Would also allow to implement EXT_texture_swizzle (basically the state tracker when needing a AL format would use RG, then appropriate default pipe_sampler_state swizzle which would also integrate the values from depth texture modes and EXT_texture_swizzle to map to hardware). nvidia hardware (since nv30) and amd (since r300) would work very nicely with this (though it puts the burden for selecting appropriate swizzles entirely on the state tracker). However, backends like i915/i965 and svga can't deal with this. Could potentially solve this with a additional default swizzle parameter when the texture is created (so the driver can map that back to a texture format it understands). Also, I'm not sure how that actually works when these formats are used as render targets. Maybe should just keep the formats but still provide a sampler swizzle state which the driver doesn't have to translate (that is, it would completely replace the swizzle provided by the format, we wouldn't want the driver to have to deal with combining the swizzle given by the format and the sampler swizzle state I think). It was a pretty rough idea which might not work in practice... Roland ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
