On 07.09.2008 21:35, Younes Manton wrote: >>> Samplers could be allowed to hold texture format info, thereby >>> allowing on the fly format switching. On Nvidia the texture format is >>> a property of the sampler, so it's possible to read a texture as one >>> format in one instance and another format in another instance. >>> Likewise a render target's format is emitted when it is set as a >>> target, so a format attached to pipe_framebuffer_state, or a new state >>> object analogous to a sampler (e.g. an emitter) would be very handy. >>> The format at creation time could be kept for hardware that can't do >>> this, then it's just a matter of checking/requiring that format at use >>> time matches format at creation time and signaling an error otherwise. >>> This is to get around HW limitations on render targets, so we render >>> to a texture in one format, and read from it in another format during >>> the next pass. >> Note that presently a) gallium texture format/layout/etc can't be >> changed once created, b) format is a texture property, not of the >> sampling/rendering operation. Changing a) seems impossible, especially >> considering we are moving to immutable state objects, which are much >> simpler and effictive to handle, rather than mutable state objects. If >> I understood correctly, you're asking to change b) in order to get >> around hw limitations. >> >> My first impression is that HW limitations should not be exposed in >> this way to the state tracker -- it is ok for a driver which lacks >> complete hw support for a operation to support it by breaking down in >> simpler supported operations, but that should be an implementation >> detail that should be hidden from the state tracker. That is, nvidia >> driver should have the ability to internally override texture formats >> when rendering/sampling. If the hardware limitation and the way to >> overcome is traversal to many devices, then we usually make that code >> a library which is used *inside* the pipe driver, keeping the >> state-tracker <-> pipe driver interface lean. >> >> But I am imagining the 3d state trackers here, perhaps video state >> trackers needs to be a step further aware to be useful. Could you give >> a concrete example of where and how this would be useful? > > The problem we have is that render target formats are very limited. > The input to the IDCT stage of the decoding pipeline is 12-bit signed > elements, the output is 9-bit signed elements, which then becomes the > input to the MOCOMP stage. We have R16Snorm textures, so we can > consume the 12-bit and 9-bit signed inputs well, but we can't render > to R16Snorm, or even to R16Unorm. The closest thing we have is > R8Unorm, which would be acceptable since we can lose the LSB and bias > the result to the unsigned range, but not enough HW supports that. > However, if you think of R8G8B8A8 as being 4 packed elements, we can > render to that instead and every card supports that just fine. > However, in order to consume that in the MOCOMP pass we need to > reinterpret it as an R8Unorm texture. So, as you can see we need a > surface to behave as a R8G8B8A8 (W/4)xH render target for pass A, then > as an R8 WxH texture for pass B. We could also consider R8G8B8A8 as > two elements and output 2 full 9-bit elements. Either way, we need > some sort of dynamic pixel format typing. > > It would be very difficult to do this transparently behind the scenes, > since the fragment shader code needs to be aware of the differences. > The Nvidia hardware seems to support it perfectly, since the pixel > format of a texture or render target is emitted when it is bound, > along with min/mag filter, wrap mode, etc; a buffer is just a buffer > of generic memory otherwise. I don't know much about other hardware, > but I wouldn't be surprised if Nvidia wasn't the only one that worked > like this. If this is the case, then one could argue that static pixel > formats are an artificial restriction, and that it would make more > sense for a low level API to better model how the hardware worked. But > I think keeping the format as part of the texture like it is now, so > that for hardware that didn't support this sort of thing the driver > could check that format specified in the sampler or render target > state matched the format of the texture at creation time is a good way > to satisfy both sides of the equation. > > It would probably be better to experiment with this privately and see > how it worked out if people are not currently convinced about this, > because for all I know there could be some hardware quirk that makes > this impossible or not worth using, but I just thought to mention it > in case someone had already considered this.
Dynamic format typing indeed sounds useful in some scenarios, though I'm not sure how this could be exposed in a truly generic way. You also need to consider that while you can indeed just change the format when doing for instance texture sampling, it might not work in all cases since the memory layout of the buffer might need to change (as an example, imagine hardware which needs a texture pitch of 4 pixels, so if you'd have a 20-pixel wide a8 texture, reinterpretation as r8g8b8a8 would need padding now). Roland ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
