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? -Ilyes >> Best regards, >> >> -Ilyes >> >> On Thu, Oct 25, 2012 at 2:34 AM, Kenneth Graunke <kenn...@whitecape.org> >> wrote: >>> >>> On 10/24/2012 02:44 PM, Ilyes Gouta wrote: >>>> >>>> >>>> Hi, >>>> >>>> I'm rather new to mesa and would like to ask if there is still a pure >>>> s/w rendering path for the OpenGL|ES 1.1 pipeline in mesa; that's not >>>> LLVM based (gallium) but just plain C? >>>> >>>> If yes, what's it status vs. GLES and is there any additional >>>> dependencies? >>>> >>>> Thanks, >>>> >>>> -Ilyes >>> >>> >>> >>> There are two actually: softpipe (Gallium based software rasterizer which >>> doesn't use LLVM), and swrast (the older classic Mesa software >>> rasterizer). >>> >>> swrast appears to pass a decent set of the ES 1 conformance suite. Either >>> would probably be fine. >>> >>> --Ken >> >> _______________________________________________ >> >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
