On Fri, 2010-02-12 at 09:56 -0800, Roland Scheidegger wrote: > On 12.02.2010 18:42, 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. > > Yes, for rg01 vs rg11 this is easiest. It doesn't solve the depth > texture mode problem though. > Also, we sort of have that flag already, I think there's no reason why > this needs to be separate from gl_rasterization_rules (though I guess in > that case it's a bit a misnomer...)
I'd prefer to avoid a big "I'm a GL/DX9 context" flag, and split different behaviours into different flags. Sure, a GL state tracker might set them all one way, but that doesn't mean some future state-tracker wouldn't want to use a novel combination. The GL rasterization rules flag should be renamed to reflect what it's really asking for. Keith ------------------------------------------------------------------------------ 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
