[Bf-viewport] OpenGL ES compatibility

[Brecht Van Lommel]

It might be a bit early to pin down a specific version for Blender 2.8
yet, but OpenGL 3.2-ish and OpenGL ES 3.0 seem good to me as a working
assumptions. Including Sandy Bridge through OpenGL 3.1 + extensions
makes sense.

I think there is enough work that can be done in master now with
OpenGL 2.1. How to handle Blender 2.8 branching we can worry about
later when development on that actually starts.

Shaders APIs, transformation stacks, immediate mode removal, etc, ..
all can be done in master once there is a design worked out.


On Sun, Dec 6, 2015 at 5:01 PM, Martijn Berger <martijn.berger at gmail.com> wrote:
> 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"
> "Sandy Bridge supports six OpenGL 3.3 extensions:
> ARB_vertex_type_2_10_10_10_rev, ARB_timer_query, ARB_texture_rgb10_a2ui,
> ARB_shader_bit_encoding, ARB_occlusion_query2 and
> ARB_explicit_attrib_location"
>
> That would be 3.2 without requiring ARB_texture_multisample 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
>>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>