On Fri, 2010-04-09 at 09:57 -0700, Roland Scheidegger wrote: > On 09.04.2010 18:22, José Fonseca wrote: > > On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote: > >> On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote: > >>> On 09.04.2010 17:49, Keith Whitwell wrote: > >>>> On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote: > >>>>> Module: Mesa > >>>>> Branch: gallium-resources > >>>>> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf > >>>>> URL: > >>>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf > >>>>> > >>>>> Author: Roland Scheidegger <srol...@vmware.com> > >>>>> Date: Fri Apr 9 17:44:24 2010 +0200 > >>>>> > >>>>> gallium: fix comments for changed USAGE flags > >>>>> > >>>>> --- > >>>>> > >>>>> src/gallium/auxiliary/util/u_simple_screen.h | 9 +++++---- > >>>>> src/gallium/drivers/svga/svga_winsys.h | 10 ++++------ > >>>>> src/gallium/include/pipe/p_screen.h | 2 +- > >>>>> src/gallium/include/state_tracker/sw_winsys.h | 2 +- > >>>>> 4 files changed, 11 insertions(+), 12 deletions(-) > >>>>> > >>>>> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h > >>>>> b/src/gallium/auxiliary/util/u_simple_screen.h > >>>>> index 0042277..1ba59af 100644 > >>>>> --- a/src/gallium/auxiliary/util/u_simple_screen.h > >>>>> +++ b/src/gallium/auxiliary/util/u_simple_screen.h > >>>>> @@ -73,9 +73,10 @@ struct pipe_winsys > >>>>> * window systems must then implement that interface (rather than > >>>>> the > >>>>> * other way around...). > >>>>> * > >>>>> - * usage is a bitmask of > >>>>> PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This > >>>>> - * usage argument is only an optimization hint, not a guarantee, > >>>>> therefore > >>>>> - * proper behavior must be observed in all circumstances. > >>>>> + * usage is a bitmask of PIPE_BIND_*. > >>>>> + * XXX is this true? > >>>>> + * This usage argument is only an optimization hint, not a > >>>>> guarantee, > >>>>> + * therefore proper behavior must be observed in all circumstances. > >>>> The new flags are no longer hints - they are supposed actually specify > >>>> which operations are permitted on a resource. > >>>> > >>>> Unfortunately I don't think this is very well enforced yet -- I intend > >>>> to add a "debug" layer to sit between state-tracker and driver, based on > >>>> the drivers/identity layer, which will check for violations of this & > >>>> other rules. > >>> Ok, I thought this to be the case, but wasn't sure. I'll fix the comment. > >>> In the svga code, I actually couldn't figure out the usage flags when a > >>> winsys buffer is created. It looks like usage is always 0, except for > >>> queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a > >>> resource but a winsys buffer, but as far as I can tell this ends up in a > >>> pb_buffer usage flag. Not sure if that's ok or supposed to be like that... > >> Jose has looked at this more recently than I have... > > > > pb_buffer sits between pipe driver and the winsys, and needs to pass > > custom buffer flags unmodified from svga to the winsys. > > > > SVGA_BUFFER_USAGE_PINNED is one of those usages. > So the svga winsys buffer_create function takes only custom flags, none > of the PB_USAGE ones?
Yep. That's right. All SVGA winsys buffers are identical in nature apart from the pinned vs unpinned. All winsys buffers allow for full CPU and GPU access, so these are ignored. > This is the idea I got from the code (plus the > custom flags would clearly overlap with the generic ones), and hence > what I updated the comment to (which clearly was wrong). > I'm not sure though this really works with the pb code I thought it > might do some checks on the usage flags there but if you say it works > then I better believe it... pb code does look into those flags. But I believe it pays more attention to the same kind of flags that are passed when mapping and validation time than the ones passed at buffer creation time. Anwyay, this is just from skimming the code. I did not have time to test gallium resources's svga pipe driver yet. Jose ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
