So hopefully eevee will support the new real time ray tracing features
The author seems surprised, but nVidia had actually made it clear from the very first initial presentation that GTX cards would have a fallback, just slower. The bigger problem for Eevee is the very unfortunate and badly timed choice of API, which makes it difficult to access the Vulkan-based dxr extension.
AFAIK, nVidia has no current plans to make raytracing available on OpenGL.
So it’s borderline impossible to implement Ray tracing reflection and gi for eevee ?
Well, it’s either borderline impossible, or just plain old impossible in an OpenGL application at this point. I’m no programmer though.
Note that I’m just talking about hardware raytracing on RTX, it could still be done in software via OpenCL maybe.
They need to port eevee on Vulcan api as soon as possible after the blender 2.8 release
Vulcan uses SPIR-V as shading language. Opengl uses glsl . That mean you have to rewrite EEVEE or at least change alot of the code to use automatic translation toolchain. My source for this info
So it’s is not that simple that’s a very big project
Basing Evee on OpenGL was probably the worst decision in all Blender history.
It was severly critized even when it was first announced by a lot of people.
And they were right: Technologically it is not only pretty much a dead end but also pretty much dead on arrival.
Why is it bad ? Could you explain ?
I mean they took the manhours to create a new viewport/ render engine to begin with and but created it around a legacy API whose writing was on the wall long before there ever was an Evee.
Not being on Vulkan means no hardware raytracing which a lot of game engines already have implementations for.
BF either rewrite the whole thing for Vulkan again ( which they should have done from the beginning) or just have new legacy render engine. I dont know how to call it but mismanagment.
And lets face it: No one will want to fiddle with SS reflections, shadow maps, flickering and z-fighting when they can have superior raytraced quality at the same speed elsewhere.
Sad part is that were not only a lot of voices raising these concern but also the manpower wasted that could have been spend elsewhere.
1 Like
They choose opengl because far more older computers will run blender so for me even if I have a high end machine it’s a good choice from the blender foundation ,in the feature they can port in the Vulcan API and they can have both api in one package , which is the right direction 
You dont seem to realize the amount of effort just “porting to Vulkan” entails especially on a resource constrained project as Blender.
Apart from that:
Even a 5 year 750 1GB has Vulkan support. You can find these cards in computers lying on wastegrounds.
Is there even a remotely realistic use case for a Evee user that has less of a card?
5 years old cards are pretty young gpus ,this is blender not maya ,there is many users in a third world countries that use blender ,they can’t upgrade PC very often , I’m don’t worry about the Vulcan support ,they will porting sometimes in the next 2 years , so no big deal will happen until then , Ray tracing will not get massive adoption at last in the next 3 to 5 years
I am not saying third world shouldnt be able to use Blender just not EVEE and especially not dictate pace of software development.
I ask again: What REALISTIC usecase is there for a card lower than 750 class in EVEE right now that mandates OpenGL?
They are way too slow and memory constrained anyway to be usefull for anything really.
I want to see a realistic usecase for such a card that provides something better han BI could have achieved and justifies OPENGL over Vulkan.
I don’t ret it I saw an open GL RTX Ray tracing development kit in the official NVIDIA website.
Why do you say it’s not compatible to open gl then ?
It is possible to exchange buffers between Vulkan and OpenGL, so you could use Vulkan to ray trace and OpenGL for the rest.
That would have required a time machine, since work on the new viewport started before Vulkan specs and drivers were published.
1 Like
Did you read that article you cited as source? Right in the first sentence it says that you can compile glsl shaders to SPIR-V. In addition, OpenGL 4.6 added support for SPIR-V.
u have to remember eevee developement started a long time ago before vulkan got updated, blender uses opengl for many other things, porting to vulkan is also not an easy task but there are plans for long term projects to have support for both eevee and the viewport.
here it’s listed in this task.
Eevee & Viewport Module
I am not sure about the excact time line on top of my head but dont you think it would have still been more effiecent to pull the plug on OpenGL in 2016/2017 (?) and simply base it on Vulkan from there.
Also: What is the benefit? I argue that any card not having Vulkan support is of virtually no use in current Evee due to speed and memory restrictions.
But afair it had more to do with Apple´s stance towards Vulkan than real use cases on legacy GPUs anyway.
It’s easy to say that in hindsight. At the time, the future of Vulkan was unknown, and OpenGL was (and still is) the only API that has official support across vendors and operating systems.
What would be the benefit of porting to Vulkan? Other than lots of work? Ray tracing can be implemented via shared buffers. Performance improvements will only manifest themselves when the CPU part of the OpenGL driver is the bottleneck, which as far as I can tell is not the case in Blender.
At the moment, the developer time it would take to port to Vulkan is much more needed in other places. Chasing the latest and greatest APIs just because, to fix something that isn’t broken is a luxury.
2 Likes
This would be one of the major points.
Vulkan expects the programmer to write a number of systems that have to be in place before you can actually draw things (which OpenGL gives you out of the box). This type of thing is one of the reasons why faster drawing code is possible, but the developers doing 100 percent Vulkan code now could’ve delayed 2.8’s release by a year or more (ie. there would’ve been no RC1 and likely release in July 2019).