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 <srol...@vmware.com > <mailto:srol...@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 > <srol...@vmware.com <mailto:srol...@vmware.com> > > <mailto:srol...@vmware.com <mailto:srol...@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 > > <jfons...@vmware.com <mailto:jfons...@vmware.com> > <mailto:jfons...@vmware.com <mailto:jfons...@vmware.com>> > > >> <mailto:jfons...@vmware.com <mailto:jfons...@vmware.com> > <mailto:jfons...@vmware.com <mailto:jfons...@vmware.com>>>> wrote: > > >> > > >> > > >> > > >> ----- Original Message ----- > > >> > On 14.04.2013 13:44, Jose Fonseca wrote: > > >> > > ----- Original Message ----- > > >> > >> From: Christoph Bumiller > <christoph.bumil...@speed.at <mailto:christoph.bumil...@speed.at> > > <mailto:christoph.bumil...@speed.at > <mailto:christoph.bumil...@speed.at>> > > >> <mailto:christoph.bumil...@speed.at > <mailto:christoph.bumil...@speed.at> > > <mailto:christoph.bumil...@speed.at > <mailto:christoph.bumil...@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@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org> > > <mailto:mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org>> > > <mailto:mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org> > > <mailto:mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org>>> > > >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> mesa-dev mailing list > > >> mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org> > > <mailto:mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org>> > > >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > >> > > > _______________________________________________ > > > mesa-dev mailing list > > > mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org> > <mailto:mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org>> > > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org> > <mailto:mesa-dev@lists.freedesktop.org > <mailto:mesa-dev@lists.freedesktop.org>> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
