On 03/08/2011 11:22 PM, Marek Olšák wrote:
On Tue, Mar 8, 2011 at 10:17 PM, Thomas Hellstrom
<thellst...@vmware.com <mailto:thellst...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
