----- Original Message ----- > From: Christoph Bumiller <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. 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 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. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
