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

[Dave Airlie]

On Fri, Oct 26, 2012 at 5:56 AM, Ilyes Gouta <ilyes.gouta at gmail.com> wrote:
> 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?

The backend driver does the batching.

Dave.