Page 1 of 1

Vulkan

Posted: Sun Aug 11, 2019 4:47 am
by Beshenka
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).

Re: Vulkan

Posted: Sun Aug 11, 2019 10:46 am
by Dade
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.

Re: Vulkan

Posted: Sun Aug 11, 2019 12:05 pm
by Beshenka
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

Re: Vulkan

Posted: Sun Aug 11, 2019 12:20 pm
by lacilaci
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)

Re: Vulkan

Posted: Tue Aug 13, 2019 1:53 am
by happyboy
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 :)

Re: Vulkan

Posted: Tue Aug 13, 2019 1:42 pm
by happyboy
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

Re: Vulkan

Posted: Wed Aug 14, 2019 9:19 am
by FarbigeWelt
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.