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

[Ilyes Gouta]

Hi,

On Thu, Oct 25, 2012 at 2:12 PM, Jose Fonseca <jfonseca at 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
>> <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
>>