Hi, On Thu, Oct 25, 2012 at 2:12 PM, Jose Fonseca <jfons...@vmware.com> wrote: > Gallium interface seems a good place to cleanly separate state tracking from > rendering. Everything is already done for you -- you just need to insert RPC > between Mesa state tracker and softpipe pipe driver. I belive that there was > even some attempt at doing something similar for virtualization purposes > (vgallium I believe, the only URL I could find for it was > http://spice-space.org/page/PortingVgalliumToSpice )
Alright. Indeed Gallium would then offer the (proper) split already. Any idea on the level of support for GL|ES 1.1 on gallium/softpipe? Is there a test/validation report available online? > Also, LLVM community is working on adding support to MC-JIT to run code > remotely so if you co-processor supports LLVM then there might be solution > would be to continue using llvmpipe. But this depends on LLVM upstream > completing that feature, and would require large changes in llvmpipe to make > the split between execution and compilation water tight. I can't be using LLVM (in a first step) because it would require writing a new JIT back-end for the offloading CPU (even though it's a VLIW march..). > If neither the above suites your needs or tastes, then you could of course > split the swrast too, but I suspect it would be much harder, as the Mesa <-> > driver interface is less water tight than Mesa State tracker <-> pipe driver > interface. > > Whatever you do, you should try to split between existing components and > never try splitting an existing component in the middle. Otherwise it will be > many order of magnitudes harder, and the result would probably be too complex > to merge back into Mesa upstream. That is, it would require an herculian > effort on your part, and for eternity. Whereas if you split betwen existing > components you will get results much quicker, and you might be able to > shoulder maintenance of that with the rest of the Mesa community. Sure! Thanks a lot, -Ilyes > Jose > > ----- Original Message ----- >> 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? >> >> 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
