Just an idea...
For hardware supporting arbitrary xyzw01 swizzles, reporting that e.g.
PIPE_CAP_TEXTURE_SWIZZLE is supported should be sufficient. For the other
hardware like i965, a new "swizzle[4]" parameter would need to be added to
is_format_supported. This doesn't raise hardware requirements while allowing
for more flexibility at the same time.
Marek
On Fri, Feb 12, 2010 at 6:28 PM, José Fonseca <jfons...@vmware.com> 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.
>
> 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
>
------------------------------------------------------------------------------
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
