Vulkan

Discussion related to the Engine functionality, implementations and API.
Post Reply
Beshenka
Posts: 2
Joined: Tue Jul 30, 2019 12:37 pm

Vulkan

Post by Beshenka » Sun Aug 11, 2019 4:47 am

openCL is undoubtedly a good thing. But what about Vulkan? Vulkan is the same open standard as openCL, but at the same time it is faster and more modern. For example, otoy even switch from cuda to it, despite the fact that octane originally used cuda (by the way, the speedup from the transition to Vulkan is quite good). I think that the transition to the Vulkan would be a good idea because speedup is not superfluous (and i hate compiling opencl kernels).
Should we expect this?

I would also like to ask whether it is possible to use nvidia optix framework (for turing RTX) with openCL? (well, if suddenly you do not want to use the vulkan).

User avatar
Dade
Developer
Developer
Posts: 2820
Joined: Mon Dec 04, 2017 8:36 pm

Re: Vulkan

Post by Dade » Sun Aug 11, 2019 10:46 am

Beshenka wrote:
Sun Aug 11, 2019 4:47 am
openCL is undoubtedly a good thing. But what about Vulkan? Vulkan is the same open standard as openCL, but at the same time it is faster and more modern. For example, otoy even switch from cuda to it, despite the fact that octane originally used cuda (by the way, the speedup from the transition to Vulkan is quite good). I think that the transition to the Vulkan would be a good idea because speedup is not superfluous (and i hate compiling opencl kernels).
Should we expect this?
OpenCL is pretty much dead, we are also stuck to v1.2 (i.e. the only version officially supported by NVIDIA): it is a damn prehistoric tool. So it is an open problem.

Vulkan is an option, CUDA is the other one.

Few considerations:

1) already maintaining 2 code versions (C++ and OpenCL) is a pain, there is no way we are going to support an additional standard (Vulkan or CUDA);

2) given #1, the only option is about replacing current OpenCL code with something else;

3) replacing the current OpenCL with something else is a LOT of work to land pretty much about where we are now (i.e. not very exciting...);

4) Vulkan is not a computing oriented API, it is more intended for classic rasterization workloads, not exactly the best tool for the job;

5) Khronos hasn't exactly a bright score, if we replace OpenCL with Vulkan, are we going to need to replace Vulkan with something else in 5 years ?

6) CUDA is the best option, hand down but using a proprietary API ... on my dead body.

I look with a bit more interest to CUDA than Vulkan but I have some serious doubt switching is a viable option for this project (i.e. we don't have the resources). Anyway it is an open problem.
Beshenka wrote:
Sun Aug 11, 2019 4:47 am
I would also like to ask whether it is possible to use nvidia optix framework (for turing RTX) with openCL? (well, if suddenly you do not want to use the vulkan).
NVIDIA exposes RTX with a Vulkan extension, Khronos claims they are also working on Vulkan-OpenCL interoperability. When it is available and supported by NVIDIA, we can support RTX by replacing the ray/triangles intersection OpenCL kernel with a Vulkan kernel (i.e. it is about replacing a single piece of code, not all; a viable option).

May be AMD will offer an OpenCL extension when they will support hardware (or software) ray tracing. But NVIDIA is never going to offer something for OpenCL for obvious reasons.

P.S. Otoy always promises a lot, it is the delivery phase to be a bit more questionable.
Support LuxCoreRender project with salts and bounties

Beshenka
Posts: 2
Joined: Tue Jul 30, 2019 12:37 pm

Re: Vulkan

Post by Beshenka » Sun Aug 11, 2019 12:05 pm

it's really sad when the industry is being taken over by proprietary software. Well, thanks for the answer. You do a great job, thank you very much <3

User avatar
lacilaci
Donor
Donor
Posts: 1380
Joined: Fri May 04, 2018 5:16 am

Re: Vulkan

Post by lacilaci » Sun Aug 11, 2019 12:20 pm

I think nvidia is becoming more open source friendly lately. Some hw docs released for open source driver developers etc
..

Anyway, as a user I see a lot of potential of luxcore even if it was c++ only (cpu only). The performance is at the moment very good even on cpu and not even mentioning cheap availability of 32GB+ Ram sizes.

My lame, amateur opinion right now is that it would be best to wait what becomes the best standard next (optix or whatever amd is cooking) and in the meantime focus on c++ and mantain opencl only if it can keep up.

I love the gpu rendering performance but if opencl is going deadend I'd either switch to some cuda or optix renderer (cycles, octane) or go with cpu rendering (if corona finaly makes blender plugin or luxcore gets some advanced cpu features like pathguiding)

happyboy
Posts: 49
Joined: Sat Jun 22, 2019 5:39 am

Re: Vulkan

Post by happyboy » Tue Aug 13, 2019 1:53 am

Dade wrote:
Sun Aug 11, 2019 10:46 am
NVIDIA exposes RTX with a Vulkan extension, Khronos claims they are also working on Vulkan-OpenCL interoperability. When it is available and supported by NVIDIA, we can support RTX by replacing the ray/triangles intersection OpenCL kernel with a Vulkan kernel (i.e. it is about replacing a single piece of code, not all; a viable option).
What about refactoring our OpenCL codebase and try use google's clspv to cross-compile most part to vulkan compute shaders?
https://github.com/google/clspv/blob/ma ... nVulkan.md

I'm not familiar with OpenCL so I don't know how hard it will be. But this conversion doesn't need deep understanding of rendering, so more people can help. For example, if our company finally decided to use LuxCore in our product, we might even hire a full-time programmer to work on LuxCore (integration, testing, bug-reporting or bug-fixing etc). And although it's very difficult to hire rendering programmers here, it's a lot easier to hire people to aid the OpenCL -> Vulkan transtion :)

happyboy
Posts: 49
Joined: Sat Jun 22, 2019 5:39 am

Re: Vulkan

Post by happyboy » Tue Aug 13, 2019 1:42 pm

Dade wrote:
Sun Aug 11, 2019 10:46 am
6) CUDA is the best option, hand down but using a proprietary API ... on my dead body.
What about HIP?
https://github.com/ROCm-Developer-Tools/HIP

User avatar
FarbigeWelt
Donor
Donor
Posts: 789
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: Vulkan

Post by FarbigeWelt » Wed Aug 14, 2019 9:19 am

happyboy wrote:
Tue Aug 13, 2019 1:42 pm
Dade wrote:
Sun Aug 11, 2019 10:46 am
6) CUDA is the best option, hand down but using a proprietary API ... on my dead body.
What about HIP?
https://github.com/ROCm-Developer-Tools/HIP
Sounds pretty useful and seems a very good solution.

HIP uses ROCm for AMD graphic cards (only GPU, APU in CPU are not supported).
„The following list of GPUs are enabled in the ROCm software, though full support is not guaranteed:
GFX7 GPUs
"Hawaii" chips, such as the AMD Radeon R9 390X and FirePro W9100“

Dade‘s AMD card has a Hawaii chip. Maybe ROCm works as well as current openCL drivers for Hawaii, they have some limitations Dade knows how to avoid and work around.
160.8 | 42.8 (10.7) Gfp / Windows 10 Pro, intel i7 4770K@3.5, 32 GB | AMD R9 290x+RX 5700 XT, 4/8 GB
17.3 | 19.0 ( 4.7) Gfp / macOS X 13.6, iMac 27'', 2010, intel i7 870@2.93, 24 GB | ATI Radeon HD 5750, 1 GB
#luxcorerender | Gfp = SFFT Gflops

Post Reply