[Bf-committers] proposal: OpenGL cleanup in master

[Mike Erwin]

Yup, there's definitely interest in Vulkan for a future version of Blender.

Reasons to wait: like you say, many GPUs won't be supported, and Blender is
"3D for everyone" (within reason). Also we don't yet know if Apple will
adopt Vulkan and dropping Mac support is not an option.

In a few years we'll know more and can exploit its awesomeness!

During the heavy GL recode for 2.8 (not the cleanup proposed above) we
should be mindful of a possible future migration to Vulkan. Not rasterize
ourselves into a corner.

On Saturday, November 21, 2015, Joshua Lotfi <kernel-dev at apermund.net>
wrote:

>
> ...and then there's always Vulkan. It's supposed to improve access to
> GPU shading and compute features with one unified language (SPIR-V). Not
> only could it be used to replace OpenGL, but it could be used for
> general purpose compute uses like rendering/etc and parallel-oriented
> operations. I don't know if that's really something Blender needs
> (probably won't be compatible with more than 75% of GPU's for years).
> And I don't know if anyone is even thinking about using it, as
> CUDA/OpenCL and OpenGL 3.2 seem to be where everyone is saying things
> are going in 2.8. But it's just some thought for the future.
>
> -------- Original Message --------
> Subject: Re: [Bf-committers] proposal: OpenGL cleanup in master
> From: Antony Riakiotakis <kalast at gmail.com <javascript:;>>
> Date: Sat, November 21, 2015 1:44 am
> To: bf-blender developers <bf-committers at blender.org <javascript:;>>
>
> 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 <javascript:;>>
> 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 <javascript:;>
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org <javascript:;>
> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org <javascript:;>
> http://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire