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

[Jose Fonseca]

----- Original Message -----
> On 14.04.2013 15:34, Jose Fonseca 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.
> >> ===
[...]

> Btw., note that from my example of how swizzle *does*, but in a quirky,
> unexpected way, affect border color (if you have read that part), the
> name AFFECTS_BORDER_COLOR isn't really accurate ...

I see..

> Maybe leave the QUIRK name with an explanation that things will go wrong
> if you don't swizzle it according to texture swizzle. Or
> PIPE_CAP_BORDER_COLOR_MUST_MATCH_TEXTURE_SWIZZLE ?

In this we could define the PIPE_CAP so that other drivers can eventually advertise swizzle schemes or slightly different texture border color quirks.  That is, make the cap either an enum or bitmask, e.g.:

   get_param(PIPE_CAP_TEXTURE_BORDER_QUIRK) & PIPE_QUIRK_TEXTURE_BORDER_SWIZZLE_NOUVEAU

or something along those lines.

Anyway, provided it is well documented, I personally don't feel strongly about any particular naming.  The docs should quote / refer precisely exactly how the colors need to be swizzled, so that a new state tracker developer can immediately tell what we needs to do if he wants to support a driver with such cap.

Jose