[Mesa-dev] [PATCH] st/mesa: optionally apply texture swizzle to border color
Roland Scheidegger
sroland at vmware.com
Sun Apr 14 12:13:27 PDT 2013
Ahh forget about all this.
Thanks to Christoph Bumiller for noticing me that in fact this is a
complete non-issue, since you cannot sample from integer textures _at
all_ with d3d10. Only ld, hence no sampler and no border color...
Looks like OpenGL is a lot more permissive there (which allows you to do
pretty much anything with such textures just as ordinary textures,
except you can't use non-nearest filter).
Am 14.04.2013 20:19, schrieb Roland Scheidegger:
> No, it's not defined in GL. But it doesn't matter there anyway cause you
> can't have the same sampler (and hence border color) used for different
> textures.
>
> Roland
>
>
> Am 14.04.2013 19:53, schrieb Marek Olšák:
>> 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
>> <mailto: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>
>> > <mailto: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>>
>> > >> <mailto: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>>
>> > >> <mailto: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>>
>> > <mailto: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>
>> > <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>
>> <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>
>> <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
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list