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 <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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
