On Fri, 2010-02-12 at 09:42 -0800, Keith Whitwell wrote: > On Fri, 2010-02-12 at 09:28 -0800, 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. > > Another alternative is to just add the behaviour we really need - a > single flag at context creation time that says what the behaviour of the > sampler should be for these textures. > > Then the driver wouldn't have to worry about varients or mixing two > different expansions. Hardware (i965 at least) seems to have one global > mode to switch between these, and that's all we need to choose the right > behaviour for each state tracker. > > It might be simpler all round just to specify it at context creation.
If a context flag is enough then that sounds fine too. Jose ------------------------------------------------------------------------------ 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
