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. (Note that for instance, with i965, those two R32G32 formats mentioned here aren't really freely selectable. In OGL/DX10 mode you'll get the former, in d3d9 mode you get the latter. You can switch the mode but you'll also get different border color interpretation along with it - something which is also not specified in gallium, though I guess you could say this is tied to gl_rasterization_rules - maybe we could say the same too, R32G32 is rg01 with gl_rasterization_rules and rg11 without? Seems a bit hackish, though.). 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
