[PATCH] wip: per-pixel surface picking

[Pekka Paalanen]

On Thu, 09 Feb 2012 16:41:08 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> You are probably right that the round-trip would be bad.
> 
> Can it just use the transparency of the current buffer, rather than 
> other information that needs to be transmitted from the client?

That would be better than round-trips, sure, but there is a
possibly heavy downside, too.

This is a bit hand-wavy, since I don't have all the details, having
only followed Mesa devel and not actively working on a driver.

If we used the alpha channel of the current surface buffer, we would
need to get the alpha value (or just a boolean from alpha < threshold
test) from the buffer to the CPU. The cost of getting data from GPU
domain to CPU domain can be high, as the buffer could reside in
non-mappable VRAM, for instance, and the kernel would need to set up a
DMA transfer to get the data. Then you'd need to wait for the transfer
to complete. Depending on hardware, the transfer might also require
CPU-GPU synchronization, which is very expensive. Simply put,
glReadPixels can kill performance.

But, I think testing this would be worth it, because when the buffer
comes to the compositor, all rendering to it must have already been done
(I think), so at least we would not be waiting for the GPU to finish
client's rendering. Then if we could somehow asychronously do the whole
alpha channel read-out and compositing rendering at the same time,
maybe the cost would not be prohibitive. In any case we would be eating
a lot more system memory for every surface.

The problem is, the cost depends on the hardware and the driver, so I
don't think we want to enforce this as the only method in the protocol.


Thanks,
pq