[Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color
Marek Olšák
maraeo at gmail.com
Sun Apr 14 10:53:21 PDT 2013
If the border color is 1.0f and the format is integer, I'm not sure if the
behavior is defined in GL, but I think r600 will return 0x3f800000, which
is fine.
No, I cannot convert the border color to any other type, because the
original type is UNKNOWN after glTexParameter returns. Also, the border
color is not clamped in GL.
Marek
On Sun, Apr 14, 2013 at 7:32 PM, Roland Scheidegger <sroland at vmware.com>wrote:
> Am 14.04.2013 18:55, schrieb Marek Olšák:
> > I think the hardware doesn't care what the border color type is. I think
> > the border color is "fetched" from the sampler state, which should be a
> > memcpy. If no texels are fetched from the texture, the border color is
> > copied to the destination register. If I set the texture hardware format
> > to "invalid", the texture fetch instructions always return the border
> > color, which suggests the hardware really does not care about the type.
> But d3d always sets border color as float. So if your border color is
> 1.0, I doubt setting the fetched texel value of a int texture to
> 0x3f800000 when you hit the border is the right thing to do (but it
> would obviously be correct for a float texture). You certainly can
> convert those float values to int type in your driver, but it will not
> work if the same sampler is used both for int and float textures.
> Though actually the spec also says
> (
> http://msdn.microsoft.com/de-ch/library/windows/desktop/bb172415%28v=vs.85%29.aspx
> )
> border color must be between 0.0 and 1.0. Doesn't make a whole lot of
> sense for integer textures (as the only possible values when converting
> to int would be 0 and 1). So something's clearly missing here...
>
>
> >
> > OpenGL also doesn't care what the border color type is after it is set,
> > because the state is a union type.
> Yes of course.
>
> Roland
>
>
> >
> > Marek
> >
> >
> >
> > On Sun, Apr 14, 2013 at 6:20 PM, Roland Scheidegger <sroland at vmware.com
> > <mailto:sroland at vmware.com>> wrote:
> >
> > Oh and btw how does this work for real hw, if the hardware indeed
> > interpets the border color value according to format?
> > Are there some bits to set that the border color value is either
> > interpreted according to format (useful for opengl) or always as
> float
> > (useful for d3d10)? Or how else do you use the same sampler for
> > different int/float textures?
> > This discrepancy between OpenGL and d3d10 is quite a mess.
> >
> > Roland
> >
> >
> >
> > Am 14.04.2013 17:45, schrieb Roland Scheidegger:
> > > Yeah it is ok for OpenGL. I guess for d3d10 we'd probably need to
> > create
> > > another sampler if the same sampler is used for both int and float
> > > textures. Or just supply both int and float border colors to the
> > sample
> > > code (but making it work both for opengl and d3d would be ugly).
> > FWIW it
> > > looks like some intel hw also seems to require multiple border
> color
> > > values (and 6!!! ones at that), and the hw just picks the right
> value
> > > based on format. Though for some reason the only border color
> > format it
> > > does _not_ have is 32bit int, so it looks this does absolutely
> nothing
> > > to make both float and 32bit int colors work with the same sampler
> > > simultaneously (and I guess 32bit int is probably the reason opengl
> > > specifies those as ints, since you can't get accurate values with
> > floats).
> > > The swizzling looks like an orthogonal issue to that, however.
> > >
> > > Roland
> > >
> > >
> > > Am 14.04.2013 16:18, schrieb Marek Olšák:
> > >> 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 <mailto:jfonseca at vmware.com>
> > >> <mailto:jfonseca at vmware.com <mailto: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
> > <mailto:christoph.bumiller at speed.at>
> > >> <mailto:christoph.bumiller at speed.at
> > <mailto: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
> > <mailto:mesa-dev at lists.freedesktop.org>
> > <mailto:mesa-dev at lists.freedesktop.org
> > <mailto:mesa-dev at lists.freedesktop.org>>
> > >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> mesa-dev mailing list
> > >> mesa-dev at lists.freedesktop.org
> > <mailto:mesa-dev at lists.freedesktop.org>
> > >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > >>
> > > _______________________________________________
> > > mesa-dev mailing list
> > > mesa-dev at lists.freedesktop.org <mailto:
> mesa-dev at lists.freedesktop.org>
> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org <mailto:
> 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/79c0ac35/attachment-0001.html>
More information about the mesa-dev
mailing list