Roland Scheidegger wrote on 2010-02-12 20:55: > 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. > > If we do care about those three drivers, the texture swizzle would have to be an optional feature. That means it won't solve our current problem and we need to look for a temporary solution.
Having formats like RGBA32_1111_FLOAT is also not ideal, since the 1111 infix does not convey universal information about its contents, but how to treat it in a specific context (texture sampling). What happens if we allow the same surface to be used both as a vertex buffer and as a texture? What about render to vertex buffer? It looks like the only option left is contex-wide parameter that specifies doing either 0001 or 1111 format expansion in texture samplers. If we are concerned about future state trackers that would use even different scheme (and what that would be, BTW?) we either add another option or gallium is mature enough to have texture swizzle a mandatory feature. ------------------------------------------------------------------------------ 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
