2010/4/25 Kristian Høgsberg :
> On Sat, Apr 24, 2010 at 10:25 AM, Jakob Bornecrantz
>> -PUBLIC const struct st_module st_module_OpenGL_ES1 = {
>> - .api = ST_API_OPENGL_ES1,
>> - .create_api = st_manager_create_api
>> -};
>> +PUBLIC struct st_api *
>> +st_api_create_OpenGL_ES1()
>> +{
>> + re
Hi Jakob,
On Sat, Apr 24, 2010 at 10:25 PM, Jakob Bornecrantz
wrote:
> This Patch series does some minor refactoring in the st_api interface
> and some major one to st/dri.
> The first patch drops the st_module struct from st_api. This is because it
> was overlapping the st_api struct. Both repre
2010/4/25 Chia-I Wu :
> 2010/4/25 Kristian Høgsberg :
>> On Sat, Apr 24, 2010 at 10:25 AM, Jakob Bornecrantz
>>> -PUBLIC const struct st_module st_module_OpenGL_ES1 = {
>>> - .api = ST_API_OPENGL_ES1,
>>> - .create_api = st_manager_create_api
>>> -};
>>> +PUBLIC struct st_api *
>>> +st_api_crea
Now that transfers are context operations it is the driver's
responsibility to ensure that transfers happen in order with all other
context operations, so flushes and finishes inside Mesa should be no
longer necessary. The attached patch implements that.
This should proportionate significant impro
https://bugs.freedesktop.org/show_bug.cgi?id=19430
--- Comment #5 from Sven Arvidsson 2010-04-25 10:40:26 PDT ---
Created an attachment (id=35279)
--> (https://bugs.freedesktop.org/attachment.cgi?id=35279)
backtrace
With the Xserver patched for pbuffer support, I can run the Windows version of
On Thu, 2010-04-22 at 19:48 +0200, Aljoša Mohorović wrote:
> i've tried to enable webgl in chrome/webkit and firefox dev builds on
> intel and ati cards but got the same results.
> since i'm running opengl apps on both cards i guess it is something
> related with webgl implementation in browsers.
>
