[Bf-viewport] OpenGL ES compatibility

[Martijn Berger]

I think if we are not hampered by it to much allowing the Sandybrigde
hardware on intel to run would be a win.

"In practice, Sandy Bridge supports OpenGL 3.1 with all the OpenGL 3.2
extensions but ARB_texture_multisample
<https://www.opengl.org/registry/specs/ARB/texture_multisample.txt>"
"Sandy Bridge supports six OpenGL 3.3 extensions:
ARB_vertex_type_2_10_10_10_rev
<https://www.opengl.org/registry/specs/ARB/vertex_type_2_10_10_10_rev.txt>,
ARB_timer_query <https://www.opengl.org/registry/specs/ARB/timer_query.txt>,
ARB_texture_rgb10_a2ui
<https://www.opengl.org/registry/specs/ARB/texture_rgb10_a2ui.txt>,
ARB_shader_bit_encoding
<https://www.opengl.org/registry/specs/ARB/shader_bit_encoding.txt>,
ARB_occlusion_query2
<https://www.opengl.org/registry/specs/ARB/occlusion_query2.txt> and
ARB_explicit_attrib_location
<https://www.opengl.org/registry/specs/ARB/explicit_attrib_location.txt>"

That would be 3.2 without requiring ARB_texture_multisample
<https://www.opengl.org/registry/specs/ARB/texture_multisample.txt> in
practice.  Given the relatively high marketshare of these this could be a
good enough way to go.

OpenGL and its extensions and who implements what is such a mess.
I would like to look at what extensions are common in OS X 10.9 with GL 3.x
hardware to be sure what parts of OpenGL 3.3 might be a good idea to
require.


On Sun, Dec 6, 2015 at 4:40 PM, Mike Erwin <significant.bit at gmail.com>
wrote:

> On Sun, Dec 6, 2015 at 10:07 AM, Antony Riakiotakis <kalast at gmail.com>
> wrote:
>
>> For me, supporting 2.1 was more to ensure that we had broader hardware
>> support for blender. My personal aspiration was to jump immediately to 3.3
>> for blender2.8.
>>
>
> 2.1 for the rest of the Blender 2.7x line, to keep this broad hardware
> support. Then 3.2 core profile for Blender 2.8. Some users will need a new
> GPU but not most. There's no point setting it to GL 3.0 or 3.1 because
> MacOS never supported those. 3.3 might be a better target than 3.2 if we
> find a compelling reason during development.
>
> We could do the more radical forward looking changes in a branch, but on
>> the other hand we've seen what tends to happen to big branches like that
>> and we decided to better work directly in master. If others also agree too
>> then I would agree to raise the bar to 3.1.
>>
>
> For the BIG jump to GL 3, how about do that in the main Blender 2.8
> branch, not a side branch. Where it will remain in use & continuously
> tested but not interfere with the rest of the Blender 2.7x releases.
>
>
> I agree with everything said so far about ES & WebGL -- if we want to be
> compatible it should be with more capable versions like ES 3.0 and WebGL
> 2.0. Also let's not avoid features on full GL desktop/laptop just because
> they wouldn't work on a tablet.
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20151206/de462bb3/attachment.htm