[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Best practices for OpenGL ES



Am 16.01.2012 20:01, schrieb Sylvain:
> On Mon, Jan 16, 2012 at 02:28:19PM +0100, Tobias Hansen wrote:
>> * Most systems with GL (and shaders) provided by Mesa also support
GLES(2).
>
> Do you have examples on how this is done?
>
> Last time I checked, I could only find Mesa's EGL
> src/egl/opengles2/tri demo which display a triangle through OpenGL ES
> shaders + GLES2 EGL initialization, and I couldn't figure if:
> - it happened to work in an OpenGL non-ES environment or,
> - if Mesa was truly enforcing OpenGL ES mode


I don't understand exactly what you want to know, but if the program is
linked with libGLESv2 and libEGL instead of libGL and initialization is
done using EGL, it uses GLES2. The program I mentioned earlier which
works with GLES2 on Debian is sludge (opensludge.sourceforge.net).


> Also I wonder how the existing libraries/frameworks (SDL, SFML,
> Pyglet, etc.)  behave in that regard (Do they support OpenGL ES-only
> GPUs? Can they initialize an OpenGL ES context?).

SDL 1.2 works alongside GLES, but doesn't provide any specific support.
Initialization has to be done using EGL. SDL 1.3 has some support for
GLES I think.

Am 16.01.2012 23:40, schrieb Sylvain:
> On Mon, Jan 16, 2012 at 08:29:37PM +0100, Julien Cristau wrote:
>> On Mon, Jan 16, 2012 at 20:01:51 +0100, Sylvain wrote:
>>
>>> Alternatively, can the packages detect the OpenGL version at runtime
>>> and act accordingly?
>>>
>> You can detect the GL version and extensions at runtime as much as you
>> want.  GL vs GLES is not the same thing though.
> 
> Yeah, I meant "detect the OpenGL ES/non-ES variant at runtime and act
> accordingly".

No, the program can't be linked against both libGLESv2 and libGL.

Best regards,
Tobias


Reply to: