On Sat, 2011-01-29 at 15:12 -0800, Marek Olšák wrote: > > > Hi, > > I am proposing to add a pointer to a user buffer in pipe_resource. > There are two reasons for this: > > 1) I would like to have a way to query outside of a driver whether a > buffer is a user buffer. Simply comparing the pointer with NULL would > do the trick. > > 2) I would like to efficiently obtain a pointer to a user buffer > outside of a driver without going through the sequence of functions > get_transfer, transfer_map, transfer_unmap, and transfer_destroy. > > This will allow to move more driver-specific code to auxiliary/util. > >
Marek, I have to say my preference would have been to see user buffers fade away in favour of things like inline transfers. That said you're much more active than I am in looking at this right now, so I don't want to get in the way of your progress. I guess my biggest problem with user buffers is how poorly defined their semantics are. For instance, what does it really mean to get write transfer into a userbuffer? Will you be updating the original application-owned memory? And user-buffers tend not to stay user-buffers - they can be promoted to regular buffers behind the scenes by the driver. Would that be reflected in this interface somehow? From the point of view of recording, replaying, debugging, remoting, etc. at the gallium boundary, it's preferable if all actions are interposable - ie. all actions are mediated by a function call of some sort into the gallium interface. Giving a component a direct memory access into buffer contents would tend to defeat that and make record/replay of that action difficult. Is it possible to get a description of what you're doing at a slightly higher level to try and understand if there's a solution without these drawbacks? Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
