<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 03/08/2011 11:22 PM, Marek Olšák wrote: <blockquote cite="mid:AANLkTik+j6Bfb6AC+CHamxFdYj9TUOpdF=D8jeStkP2M@mail.gmail.com" type="cite"> <div class="gmail_quote">On Tue, Mar 8, 2011 at 10:17 PM, Thomas Hellstrom <<a moz-do-not-send="true" href="mailto:thellstrom@vmware.com">thellstrom@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On 03/08/2011 05:11 PM, José Fonseca wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Mon, 2011-03-07 at 02:38 -0800, Keith Whitwell wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2) is_resource_referenced Now that the transfer functions are in pipe_context, is this hook really necessary? </blockquote> 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. </blockquote> 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. </blockquote> </div> 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. </blockquote> </div> 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. </blockquote> 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. <blockquote cite="mid:AANLkTik+j6Bfb6AC+CHamxFdYj9TUOpdF=D8jeStkP2M@mail.gmail.com" type="cite">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. </blockquote> 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 <blockquote cite="mid:AANLkTik+j6Bfb6AC+CHamxFdYj9TUOpdF=D8jeStkP2M@mail.gmail.com" type="cite"> Marek </blockquote> </body> </html>