Hi Dave,
On Thu, Oct 25, 2012 at 11:22 PM, Dave Airlie wrote:
> On Thu, Oct 25, 2012 at 11:12 PM, Jose Fonseca 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
On Thu, Oct 25, 2012 at 11:12 PM, Jose Fonseca 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
> ev
On Fri, Oct 26, 2012 at 5:56 AM, Ilyes Gouta wrote:
> Hi,
>
> On Thu, Oct 25, 2012 at 7:40 PM, Ian Romanick 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 ho
Hi,
On Thu, Oct 25, 2012 at 7:40 PM, Ian Romanick 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/
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 sh
Hi,
On Thu, Oct 25, 2012 at 2:12 PM, Jose Fonseca 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
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 p
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.
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 depende
On Thu, Oct 25, 2012 at 7:44 AM, 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?
Yes softpipe, but I've no idea how it does at GLES,
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
_
11 matches
Mail list logo