[Bf-committers] proposal: OpenGL cleanup in master

Mike Erwin significant.bit at gmail.com
Sun Nov 22 01:40:46 CET 2015


Cool, glad for the enthusiasm!

It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
newer systems have GL 2.1 built in. Old low-end Macs might fall back to
software rendering for certain features but won't throw an error or catch
on fire.

That set of Radeons Brecht listed support up to GL 3.3 so should all work
in Blender 2.8 too! I'm not as familiar with nVidia's stuff.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis <kalast at gmail.com>
wrote:

> Yes, let's do it for 2.77. We are supposed to be able to break
> compatibility now since we are transitioning to 2.8. I know people are
> reluctant to drop compatibility because of the flak from a few users
> with old hardware but we won't be able to do anything if we keep
> postponing changes here.
>
> I suggest we make official final decision tomorrow in meeting. I hope
> there is no more time needed to consider things here, this has been
> discussed again and again during the last year and most people agree
> with the change.
>
> Then it's GHOST patch time and finally everyone can start refactoring
> code with shaders for fancy UI and display stuff :).
>
> On 21/11/2015, Brecht Van Lommel <brechtvanlommel at pandora.be> wrote:
> > As I understand it, with OpenGL 2.1  the minimum requirements would be
> > effectively:
> >
> > * NVidia Geforce FX, Gerforce 6xxxx and newer (released in 2003)
> > * AMD Radeon R600+, Radeon HD, and newer (released in 2006)
> > * Intel HD graphics or newer (released in 2010), some older cards
> > might still work on OS X and Linux
> >
> > Mainly users with older Intel GMA graphics would be affected. That
> > sounds reasonable to me but we are raising the hardware bar for
> > Blender 2.77 then, right?
> >
> > I totally support doing this in master. Doing OpenGL refactoring in
> > big branches hasn't worked well in the past, better to do it
> > incrementally. I can help with some refactoring and code review.
> >
> > On Sat, Nov 21, 2015 at 8:44 AM, Antony Riakiotakis <kalast at gmail.com>
> > wrote:
> >> You have my sword. And my axe. And my bow.
> >> I could trickle some free time on this, though not terribly much
> >> unfortunately.
> >>
> >> I definitely vote to do this on master/or current full dev branch (2.8
> >> branch?) when that changes. The previous approach of dumping chunks of
> >> code in a big branch that will code-rot as soon as time or energy
> >> dries out just does not work for such a big project in my opinion. We
> >> need an approach that will let us work on this incrementally.
> >>
> >> We should communicate well, with screams, on the street to
> >> unsuspecting pedestrians and on the net to unsuspecting surfers, posts
> >> on blender.org, in the manual and with ugly message boxes with bright
> >> flashing red letters (OK, I admit that might be pushing it a little
> >> bit), especially for the windows and mac people, that system
> >> requirements are now raised to 2.1, and add the relevant checks and
> >> warnings in GHOST to ensure that people who try to use blender without
> >> it, cannot do so anymore. Current approach on Windows is just spawning
> >> a warning messagebox. We can leave that in but also quit blender in
> >> case it does not meet our requirements, and also expand to a similar
> >> approach for other OSs.
> >>
> >> On 21/11/2015, Mike Erwin <significant.bit at gmail.com> wrote:
> >>> Hi devs,
> >>>
> >>> I was responding to something in bf-viewport but could use a wider set
> >>> of
> >>> people to either agree or put a stop to this madness before it's too
> >>> late.
> >>> :)
> >>>
> >>> I'd like to start basic GL cleanup in master ASAP. By this I mean set
> GL
> >>> 2.1 as a baseline and convert all code that uses obsolete extensions to
> >>> the
> >>> functions/enums provided by GL itself. Much of this is simply deleting
> >>> ARB
> >>> or EXT, and removing checks for GL features that are guaranteed in 2.1.
> >>> No
> >>> new features, no major rewriting, just get the code up to spec and
> ready
> >>> to
> >>> branch for the bigger GL 3.2 upgrade.
> >>>
> >>> Staged migration of OpenGL:
> >>> now --> GL 2.1 (all platforms, soon)
> >>> --> 3.2 compatibility profile (Windows & Linux)
> >>> --> 3.2 core profile (all platforms, in time for Blender 2.8)
> >>>
> >>> That final transition will be the most work. The first transition can
> be
> >>> done NOW and doesn't involve any design really -- just a plan of what
> to
> >>> remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop
> >>> will
> >>> let us clean up a lot of legacy crap without raising the hardware bar.
> >>>
> >>> Is anyone opposed to this? Anyone eager to help?
> >>>
> >>> Mike Erwin
> >>> musician, naturalist, pixel pusher, hacker extraordinaire
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list