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.
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
