[Mesa-dev] 7 questions and proposals about changes in the Gallium interface

[Thomas Hellstrom]

On 03/08/2011 11:22 PM, Marek Olšák wrote:
> On Tue, Mar 8, 2011 at 10:17 PM, Thomas Hellstrom 
> <thellstrom at vmware.com <mailto:thellstrom at vmware.com>> wrote:
>
>     On 03/08/2011 05:11 PM, José Fonseca wrote:
>
>         On Mon, 2011-03-07 at 02:38 -0800, Keith Whitwell wrote:
>
>             On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
>
>                 2) is_resource_referenced
>
>                 Now that the transfer functions are in pipe_context,
>                 is this hook
>                 really
>                 necessary?
>
>             Good question.  I'd like to see those functions go away as
>             they are
>             round-trips baked into the interface which is a pain if
>             you try and
>             remote this stuff.
>
>             I guess you'd still need to catch the write-after-read
>             case within a
>             single context and turn that into a flush.
>
>             I think others (Jose in particular) should comment, but I
>             suspect that
>             individual drivers could now do this internally&  not need
>             to expose the
>             interface in gallium.
>
>         That's correct. State trackers no longer need this. This
>         interface can
>         be removed, and drivers that need it internally should be
>         updated to use
>         internal private interfaces.
>
>
>     One should remember, though, that with the state tracker construct
>
>     if (is_resource_referenced())
>      flush();
>
>     this must not be replaced with an unconditional flush, since that
>     may be very wasteful on some hardware. This means that drivers
>     need to be converted to do the necessary flushing themselves if
>     this interface is removed. Otherwise they will misrender.
>
>
> Please note that, as mentioned before, st/mesa doesn't use 
> is_resource_referenced anymore and it doesn't call flush either most 
> of the time (or put better, it shouldn't at all). If there was any 
> misrendering, people would notice. So the drivers are most probably 
> already converted to cope with that. 

OK. I hadn't followed development close enough to note that they have 
gone away. I had some simple tests lying around to detect these render 
failures. Let's see if I can dig those up and perhaps push to demos.


> As for PIPE_FLUSH_RENDER_CACHE, the functions set_framebuffer_state, 
> resource_copy_region, and get_transfer should flush the framebuffer 
> cache if needed, thus that flag isn't needed either (and most drivers 
> don't use it anyway). I have also seen this usage:
>
> {
>     if (is_resource_referenced())
>         flush();
>     get_transfer();
> }
>
> This flush can't be more pointless. Note that drivers can internally 
> use the 3D engine to copy the resource to RAM for the mapped memory to 
> be cached. So it would end up doing this:
>
> {
>    if (is_resource_referenced())
>       flush();
>    resource_copy_to_RAM();
>    flush();
> }
>
> Yay, double flush.


Yes, I beleive I'm the one guilty of those constructs. They were 
intended to remedy the following situation, (where a transfer is a 
direct map).

write_to_resource();
render_using_written_data()
write_to_resource();
render_using_written_data().

Here we *must* flush after the first render, and wait for resource idle 
to render correctly.

Anyway, the reason that this ended up in the state tracker in the first 
place was IIRC that there were no context associated with transfers. As 
you point out, now that's been changed, this should really be taken care 
of by the driver.

/Thomas









>
> Marek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110309/3052f250/attachment-0001.htm>