On Mon, Sep 8, 2008 at 11:08 PM, Stephane Marchesin <[EMAIL PROTECTED]> wrote: > On Mon, Sep 8, 2008 at 4:04 PM, Roland Scheidegger > <[EMAIL PROTECTED]> wrote: >> 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). >> > > Well you are right, but we could introduce a request for surface > compatibility (or even a surface conversion request) that the driver > could implement as it wants (either as a noop or as a format > conversion copy, possibly with very little overhead). This is going to > be useful for all GPGPU stuff...
I think such conversion interface is probably the best one on the long term. There is already an interface pipe_screen->texture_blanket which can be used to create a new texture over an existing piece of memory, so you can use it to do a texture conversion by creating a texture on top of another texture's memory, but it will do nothing to ensure alignment restrictions are indeed met, so is only good as a temporary hack. Jose ------------------------------------------------------------------------- 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
