On 12.02.2010 20:20, Corbin Simpson wrote: > On Fri, Feb 12, 2010 at 10:49 AM, Brian Paul <bri...@vmware.com> wrote: >> Roland Scheidegger wrote: >>> On 12.02.2010 19:00, Keith Whitwell wrote: >>>> 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. >>>> >>> Ok, makes sense. So gl_rasterization_rules should be like pixel_center_half? >>> And would a new flag for the unused channel expansion in textures >>> sampling also include the different texture border sampling rules or >>> should that also be separate (though i965 driver would need to decide >>> what rules it wants to follow if they are different...). >> >> I think we need per-sampler texture swizzles. That would solve three >> problems: >> >> 1. GL vs. D3D 9 vs. D3D 10 texture component mappings >> 2. GL_DEPTH_TEXTURE_MODE >> 3. GL_EXT/ARB_texture_swizzle (part of GL 3.3 and later) >> >> This potentially requires shaders to be recompiled in response to >> texture sampler state, but we're already doing that in some cases. >> And it's not state that changes often. >> >> -Brian > > This. r300g already gave up on the shader recompile thing; we now have > a setup where the shaders will be recompiled until they match, and > then re-cached, so a pathological case might end up attaching ten or > more HW shaders to one TGSI stream. Hardly ideal, but as everybody > else has noticed, it's kind of unavoidable. > > So... who doesn't have per-sampler texture swizzling? Also should the > default for R and RG be (r, 0, 0, 1) or (r, 1, 1, 1)? Inquiring minds > want to know, and settling those blanks now rather than later would be > *awesome*.
For "real" hardware, i915, i965. svga also can't support this. I guess the software drivers could support it easily. R should be (r, 0, 0, 1) currently. 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
