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

[Ilyes Gouta]

Hi,

On Thu, Oct 25, 2012 at 7:40 PM, Ian Romanick <idr at 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 <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
>>
>