Brian Paul wrote:
> Ben Skeggs wrote:
>> I've been playing gallium on NV40 hardware a bit this week, so far it
>> seems very nice. However... :)
>>
>> The hardware supports selective clearing of each channel of the primary
>> render target, depth, and stencil buffers in a single operation. The
>> current buffer clear interface is called with separate pipe_surface
>> structs for each GL_x_BUFFER_BIT, which makes it difficult to use this
>> functionality (which is somewhat faster when clearing both colour and
>> depth/stencil buffers at the same time).
>>
>> Is there any plan for a pipe->fb_clear() (for example) interface, which
>> would pass in a bit mask saying "clear these buffers that are currently
>> bound to the framebuffer", similar to the interface in the "old" driver
>> model?
>
> If you can also specify the channel mask for clearing each buffer, you'd
> probably want something like:
>
> clear(uint numSurfaces, pipe_surface **surfaces, const uint *masks)
I see reasonable uses for clearing fullscreen color, depth and stencil
independently. There's also a case that we should be able to pass down
a list of fullscreen clears so that the driver can process them as
efficiently as possible.
I'm totally unconvinced that there is a need to provide an interface for
clearing eg. just the red channel of a color buffer.
Firstly -- who on earth does this??? It's not a common operation.
Secondly -- a lot of hardware *doesn't* support this in the natural
clear mechanism, so making this part of the core interface means we'll
end up having to encode fallback paths on that hardware.
Thirdly -- a full buffer clear is semantically different to a clear that
only touches some channels of the buffer, or which only touches a
rectangular subset of the buffer. A full clear means that the old
buffer can be discarded entirely if the driver desires, and this is
actually a very useful thing to know.
The unfortunate exception to all this is the z24s8 depth/stencil buffer.
Clearing depth and stencil independently *is* a common/sensible thing to
do, so it is worthwhile to make this part of the driver interface in
case the hardware has a fast path for this.
Things like clear-red-channel, or clear-sub-rectangle are basically just
special cases of rendering operations. At this point I'm very happy to
see these translated to triangle rendering and handled by the main
driver path.
We *will* have an extension mechanism in Gallium - that might be the
best place to add support for hw fast paths for the oddball clear cases.
---------------------
Taking it all a step further....
What I'd like to do is to add some more structure to the commands that
the state tracker emits to the hardware driver, to try and break the
command stream up into schedulable blocks. Fullscreen clears are a good
indication of the start of such a block, as is binding a new set of
render targets. Flushes, swaps, mapping the render target, etc, are
good indications of the end of a schedulable block.
The concept I'm thinking of is something like a "scene", which is
defined as:
BeginScene:
- A set of render targets
- A depth and/or stencil buffer
- A flag for each render target and depth/stencil indicating whether
the buffer is cleared.
- The clear value for each buffer.
A whole lot of rendering.
- The render targets never change.
- We could build up a list of buffers referenced by rendering, either
as textures, vbos, or other. Maybe the driver does this internally.
EndScene:
- A flag indicating whether the z/stencil buffer contents may be
discarded. This is true on regular GLX swapbuffers.
- ?? other stuff.
The point is that you end up with effectively a rendering transaction,
with defined inputs and outputs that can be passed to a dma scheduler.
You also give the driver really explicit information on whether it can
discard buffer contents at the beginning and/or end of the scene. For
tiled/zone-rendering architectures you effectively need to compute this
information in the driver, but I believe it is likely to be helpful to
drivers of all sorts.
Anyway, this is just a concept at this point, not really sure if it will
go any further.
Keith
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
