On Fri, Oct 26, 2012 at 5:56 AM, Ilyes Gouta <ilyes.go...@gmail.com> wrote: > Hi, > > On Thu, Oct 25, 2012 at 7:40 PM, Ian Romanick <i...@freedesktop.org> wrote: >> On 10/25/2012 02:01 AM, Ilyes Gouta wrote: >>> >>> Hi, >>> >>> Alright, I'm pursuing this idea about splitting mesa into two >>> components, where state tracking happens on the host processor, >>> whereas a second co-processor gets to do the s/w rendering. The two >>> parts would be communicating via a RPC mechanism and sharing the >>> textures and render target buffers. The CPUs are in an AMP >>> configuration. >>> >>> Do you know if the code base (most importantly the data structure) is >>> already designed to achieve this? Has this been done before? >> >> >> The other approach that you could take is to make your co-processor behave >> like a GPU. Implement the software rasterizer, either from Gallium or not, >> as uploaded microcode, etc. This would make your co-processor driver look / >> act like other hardware drivers. This is the approach I was intending to >> take with a similar driver for Cell SPUs many years ago. I had done some >> initial experiments, and it looked like a promising approach. > > Yes. > > The RPC in between, besides methods invocation, could also serve/act > for a sort of 'macro'-commands buffering (asynchronous processing). > > Is commands buffering part of the gallium mesa/gallium interface, or > is it the back-end gallium driver who emits the final commands batches > to the h/w?
The backend driver does the batching. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
