[Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color

Sun Apr 14 07:18:56 PDT 2013

The border color in the sampler state is untyped and that's okay. The type
is irrelevant with nearest filtering - just memcpy the border color to the
destination register (if there is swizzling, just do what you do for
texels). With linear filtering, you can always assume it's float
(regardless of the sampler view).

Marek

On Sun, Apr 14, 2013 at 3:34 PM, Jose Fonseca <jfonseca at vmware.com> wrote:

>
>
> ----- Original Message -----
> > On 14.04.2013 13:44, Jose Fonseca wrote:
> > > ----- Original Message -----
> > >> From: Christoph Bumiller <christoph.bumiller at speed.at>
> > >>
> > >> This is the only sane solution for nv50 and nvc0 (really, trust me),
> > >> but since on other hardware the border colour is tightly coupled with
> > >> texture state they'd have to undo the swizzle, so I've added a cap.
> > >>
> > >> The name of the cap could be changed to be more descriptive, like
> > >> PIPE_CAP_TEXTURE_SWIZZLE_AFFECTS_BORDER_COLOR.
> > > Yes, please.
> > >
> > >> The dependency of update_sampler on the texture updates was
> > >> introduced to avoid doing the apply_depthmode to the swizzle twice.
> > >>
> > >> More detailed explanation of driver situation:
> > >>
> > >> No, really, don't suggest doing this in the driver. The driver has
> > >> elegantly separated texture view and sampler states (which are each
> > >> a structure in a table in VRAM and should not be updated to avoid
> > >> performance loss), and table are bound to the independent (!)
> > > I wonder if this is modeled after D3D10, where sampler state is
> independent
> > > from resource view state. Though as far as I known, D3D10's
> interpretation
> > > of texture border color does not depend on the swizzle...
> > >
> > >> texture
> > >> and sampler slots in shaders which must be separately indexable
> > >> indirectly).
> > >> So, if I was to do this in the driver, I'd have to add separate
> sampler
> > >> state object instances for each texture view with appropriately
> swizzled
> > >> border color, and there's only 16 slots, so I'd be limited to 4
> texture
> > >> units.
> > >> Not to mention the sheer insanity, ugliness and emotional pain
> incurred
> > >> when writing that code when it COULD be so easy and simple in the
> state
> > >> tracker where you know that textures and samplers are tightly coupled,
> > >> while in gallium I cannot assume that to be the case.
> > > You wouldn't really need to create all state combinations: if you known
> > > that textures and samplers are tightly coupled, then caching the
> actually
> > > used combinations will get you exactly the same behavior, without
> losing
> > > performance or generality.  But granted, this would require more
> effort.
> >
> > The emphasize being on "IF I knew" (that they're tighly coupled). If I
> > did, I could switch to linked mode where the card automatically uses the
> > view index as sampler index, ignoring the actual sampler index, and
> > validate them together.
> > However, that only applies to 3D, not to COMPUTE (which means that GL
> > compute shaders will still have the problem), and I'd have to support
> > both variants for state trackers that do not allow the coupling, and we
> > need a way for the state tracker to actually tell us what it wants. All
> > that makes it even quirkier.
> >
> > > Also please spare a thought for other state trackers -- and I'm not
> even
> > > talking about a potential D3D10 state tracker for which your driver
> would
> > > be unusable --, even inside Mesa: it seems like
> > > src/gallium/state_trackers/vega uses both texture border and swizzle,
> > > probably vl state tracker too, so your driver will be busted on those
> > > state trackers. These need to be
> >
> > It already is busted. It's also busted on r600 where making border color
> > + swizzle work properly isn't even POSSIBLE (according to the radeon
> guys).
> >
> > Maybe not for vega, it doesn't use a permutational swizzle, it just sets
> > components to PIPE_SWIZZLE_ONE, and incidentally the ZERO/ONE swizzles
> > do affect the border color. As far as I can tell, it looks something
> > like this (if you're interested; the exact behaviour seems not supposed
> > to be made use of):
> >
> > ===
> > In the format description (including swizzle), each color component of
> > RGBA (as seen by the shader) gets mapped a memory component
> > {C0,C1,C2,C3} or {ZERO,ONE_INT,ONE_FLOAT}.
> >
> > When a memory (!) component (Cx) is first encountered when going through
> > RGBA, it is assigned the SAMPLER_BORDER_COLOR component value for that
> > component, and if the memory component is encountered again (because of
> > swizzle), that same value will be used.
> >
> > So, assuming memory format RGBA and the swizzle 1RBG:
> > R = ONE
> > G = C0
> > B = C2
> > A = C1
> > the border colour will be SAMPLER_BORDER_COLOR.1GBA.
> >
> > The resulting border colour with swizzle applied to the sampler would be
> > (lowercase being user values):
> > R=1
> > G=r
> > B=b
> > A=g
> >
> > resulting in 1rbg, which works out.
> > ===
> >
> > >  updated -- maybe the burden of considering this state can be lifted
> onto
> > >  some helper functinons -- if not, these state trackers should at
> least be
> > >  updated to abort/warn when the cap is set.
> > >
> > > But I'm not really objecting -- as texture border seems fundamentally
> > > quirky state.  But before proceeding with this I'd like us to consider
> > > another texture border quirk while we are at it.
> > >
> > > The other quirk is the integer vs float texture border colors.  Roland
> can
> > > probably talk a bit more about it as he was the one who came across it.
> > > In a few words, the interpretation of texture border color union
> depends
> > > on the format in the sampler view state (whether it's a pure integer
> > > format or not).
> > >
> > > So, I wonder how integer vs float texture border colors will fit in
> your
> > > driver's "elegantly separated texture view and sampler states", or any
> > > other driver for that matter.  That is, will the world need a
> > > PIPE_CAP_SAMPLER_VIEW_FORMAT_VIEW_AFFECTS_TEXTURE_BORDER_COLOR too?
>  If so
> > > then maybe we want to lump these two things together.
> >
> > No, you can relax there, because using a sampler with integer border
> > colors with a float texture view (which doesn't happen in OpenGL) or
> > vice versa is not SUPPOSED to work (or even, supposed to not work),
> > while texture swizzle IS, it has no such incompatibility.
>
> Fair enough. But note that Gallium pipe_sampler_state's border_color
> member doesn't describe whether it is float or integer.
>
> Furthermore, given that cso module is not able to distinguish a sampler
> state with (1.0f, 1.0f, 1.0f, 1.0f) border color, from one with
> (0x3f800000U, 0x3f800000U, 0x3f800000U, 0x3f800000U), it would happily
> create the same driver handle for both.
>
> That is, even if this situation doesn't happen with OpenGL, it's still not
> clear how will drivers handle it.
>
> Also D3D10 does allow using sample sampler state with both integer/float
> texture views, although D3D10's texture borders are always float regardless
> (even for integer formats), so it has no ambiguities either.
>
> Jose
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130414/71ed493b/attachment-0001.html>