2010/4/16 Ian Romanick :
> Kristian Høgsberg wrote:
>> 2010/4/13 Chia-I Wu :
>>> These all look good to me. Two bigger issues I can think of now is the
>>> merge of GLAPI XMLs and get_gen.py. I never have a chance to look at
>>> gles version of get_gen.py, and I think it might require quite some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristian Høgsberg wrote:
> 2010/4/13 Chia-I Wu :
>> These all look good to me. Two bigger issues I can think of now is the
>> merge of GLAPI XMLs and get_gen.py. I never have a chance to look at
>> gles version of get_gen.py, and I think it might req
Kristian Høgsberg wrote:
2010/4/13 Chia-I Wu :
On Mon, Apr 12, 2010 at 12:37:10PM -0400, Kristian Høgsberg wrote:
I've been looking into the GLES1/2 support in mesa and trying to
figure out how to make it work for DRI drivers as well. The current
approach only works for gallium, and it works b
2010/4/13 Chia-I Wu :
> On Mon, Apr 12, 2010 at 12:37:10PM -0400, Kristian Høgsberg wrote:
>> I've been looking into the GLES1/2 support in mesa and trying to
>> figure out how to make it work for DRI drivers as well. The current
>> approach only works for gallium, and it works by compiling mesa c
On Mon, Apr 12, 2010 at 12:37:10PM -0400, Kristian Høgsberg wrote:
> I've been looking into the GLES1/2 support in mesa and trying to
> figure out how to make it work for DRI drivers as well. The current
> approach only works for gallium, and it works by compiling mesa core
> as different state tr
Hi,
I've been looking into the GLES1/2 support in mesa and trying to
figure out how to make it work for DRI drivers as well. The current
approach only works for gallium, and it works by compiling mesa core
as different state trackers. Each state tracker is just a thin filter
on top of the public
