On Tue, Jan 11, 2011 at 5:01 PM, Alberto Milone
wrote:
> Hi all,
>
> The attached patch adds ARL support in r600c. I followed the code in
> the equivalent commit in r600g:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=98b3f27439ba3a48286ed0d6a4467e5482b41fec
>
> Thanks a lot to Alex Deucher f
> > I tried running under valgrind, but on (eventually) getting to a page,
> > valgrind died complaining that it can't handle a general clone() call.
>
> Weird; CC'ing Julian.
V doesn't take kindly to unrestricted clone() calls. What's the
specific error message(s)?
J
_
From: Chia-I Wu
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
librari
On Sun, Jan 16, 2011 at 10:42 AM, Chia-I Wu wrote:
> On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu wrote:
>> On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu wrote:
>>> Since the same-dispatch-offset-different-glx-opcodes functions are
>>> defined in GLX, glXGetProcAddress should be a better place to han
))We don't want to require GL_ARB_ES2_compatibility. So i'll try to see how I
can emulate this functionality on desktop OpenGL.
Hi Benoit,
Would you still use native GL ES support if available on the system ? GL ES is
still the preferred path for the ATI/AMD proprietary drivers.
Thanks,
JB
__
- Original Message -
> ))We don't want to require GL_ARB_ES2_compatibility. So i'll try to
> see how I can emulate this functionality on desktop OpenGL.
>
> Hi Benoit,
>
> Would you still use native GL ES support if available on the system ?
> GL ES is still the preferred path for the ATI
Hi Olv,
Looks good to me FWIW.
I think we should avoid having opengl32.dll or the ICD loading
glapi.dll, but that's not a reason to s given you've made it optional.
Implementing EGL on Windows without implementing GL doesn't make much
sense, so we could have GLES libraries dynamically loading
On Thu, Jan 20, 2011 at 11:06 PM, Jakob Bornecrantz
wrote:
> On Sun, Jan 16, 2011 at 10:42 AM, Chia-I Wu wrote:
>> On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu wrote:
>>> On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu wrote:
Since the same-dispatch-offset-different-glx-opcodes functions are
https://bugs.freedesktop.org/show_bug.cgi?id=31940
Nirbheek Chauhan changed:
What|Removed |Added
CC||nirbheek.chau...@gmail.com
--
Config
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2011 07:48 AM, Benoit Jacob wrote:
> - Original Message -
>> ))We don't want to require GL_ARB_ES2_compatibility. So i'll try to
>> see how I can emulate this functionality on desktop OpenGL.
>>
>> Hi Benoit,
>>
>> Would you still use
))Sure! We support both OpenGL 2.1 and OpenGL ES 2.0 as back-ends, and ES is
the best since it's closest to the WebGL API (using OpenGL 2.1 forces us to do
quite costly emulation in a few cases, especially when drawing with vertex
attrib 0 array disabled).
))Naive question --- how do we get a G
Hi,
I'd like to propose a patch against glxinfo. Instead of separating the
extensions by a comma, it creates a new line. It's visually easier to
read through the extensions. Also, when doing a diff between supported
extensions by classic driver and gallium driver, it's a lot simpler to
compar
On 11-01-20 02:35 PM, Alexandre Demers wrote:
I'd like to propose a patch against glxinfo. Instead of separating the
extensions by a comma, it creates a new line. It's visually easier to
read through the extensions. Also, when doing a diff between supported
extensions by classic driver and galliu
On 01/20/2011 12:35 PM, Alexandre Demers wrote:
Hi,
I'd like to propose a patch against glxinfo. Instead of separating the
extensions by a comma, it creates a new line. It's visually easier to
read through the extensions. Also, when doing a diff between supported
extensions by classic driver and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2011 12:15 PM, Nathan Kidd wrote:
> On 11-01-20 02:35 PM, Alexandre Demers wrote:
>> I'd like to propose a patch against glxinfo. Instead of separating the
>> extensions by a comma, it creates a new line. It's visually easier to
>> read throug
On 11-01-20 03:52 PM, Brian Paul wrote:
On 01/20/2011 12:35 PM, Alexandre Demers wrote:
Hi,
I'd like to propose a patch against glxinfo. Instead of separating the
extensions by a comma, it creates a new line. It's visually easier to
read through the extensions. Also, when doing a diff between s
On Thu, Jan 20, 2011 at 6:15 PM, Alexandre Demers
wrote:
> On 11-01-20 03:52 PM, Brian Paul wrote:
>>
>> On 01/20/2011 12:35 PM, Alexandre Demers wrote:
>>>
>>> Hi,
>>>
>>> I'd like to propose a patch against glxinfo. Instead of separating the
>>> extensions by a comma, it creates a new line. It's
17 matches
Mail list logo
