[Mesa-dev] Pure OpenGL|ES 1.1 s/w renderer

[Ian Romanick]

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 <kenneth at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>