Page 1 of 2

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.

Re: Vulkan

Posted: Mon Nov 18, 2019 7:08 pm
by Dade
Intel has just announced and released the first beta version of oneAPI initiative: https://software.intel.com/en-us/oneapi/base-kit

The good new is ... it is just marketing, just another name for SYCL/OpenCL so, my bet, is:

- They are going to offer hardware ray tracing support trough Embree;
- Embree will be part of oneAPI;
- Embree will support SYCL/OpenCL.

This is a good news because there is an easy path to gradually move our code from low-level OpenCL to high-level SYCL and to integrated, from day one, any ray tracing hardware support available trough SYCL/OpenCL.

Now let's hope AMD understand it is the only possible option to replace CUDA ... don't hold your breath :roll:

P.S. SYCL is OpenCL for kids, there is full interoperability between the two so we can mix old OpenCL code with any new SYCL stuff we may want to use.

Re: Vulkan

Posted: Tue Nov 19, 2019 10:46 am
by FarbigeWelt
Dade wrote: Mon Nov 18, 2019 7:08 pm
Now let's hope AMD understand it is the only possible option to replace CUDA ... don't hold your breath :roll:
Intel is focused too much on their hardware (cpu, gpu, fpga).

Please consider AMD ROCm, HIP.

HIP: Heterogeneous-Computing Interface for Portability¶
What is Heterogeneous-Computing Interface for Portability (HIP)? It’s a C++ dialect designed to ease conversion of Cuda applications to portable C++ code. It provides a C-style API and a C++ kernel language. The C++ interface can use templates and classes across the host/kernel boundary.
The Hipify tool automates much of the conversion work by performing a source-to-source transformation from Cuda to HIP. HIP code can run on AMD hardware (through the HCC compiler) or Nvidia hardware (through the NVCC compiler) with no performance loss compared with the original Cuda code.
Programmers familiar with other GPGPU languages will find HIP very easy to learn and use. AMD platforms implement this language using the HC dialect described above, providing similar low-level control over the machine.
When to Use HIP
Use HIP when converting Cuda applications to portable C++ and for new projects that require portability between AMD and Nvidia. HIP provides a C++ development language and access to the best development tools on both platforms.
OpenCL™: Open Compute Language
What is OpenCL? It’s a framework for developing programs that can execute across a wide variety of heterogeneous platforms. AMD, Intel and Nvidia GPUs support version 1.2 of the specification, as do x86 CPUs and other devices (including FPGAs and DSPs). OpenCL provides a C run-time API and C99-based kernel language.

Wrap-Up
From a high-level perspective, ROCm delivers a rich set of tools that allow you to choose the best language for your application.
* HCC (Heterogeneous Compute Compiler) supports HC dialects
* HIP is a run-time library that layers on top of HCC (for AMD ROCm platforms; for Nvidia, it uses the NVCC compiler)
* The following will soon offer native compiler support for the GCN ISA:
* OpenCL 1.2+
* Anaconda (Python) with Numba
* 

All are open-source projects, so you can employ a fully open stack from the language down to the metal. AMD is committed to providing an open ecosystem that gives developers the ability to choose; we are excited about innovating quickly using open source and about interacting closely with our developer community. More to come soon!

https://rocm-documentation.readthedocs. ... ortability

Re: Vulkan

Posted: Tue Nov 19, 2019 10:54 am
by Dade
FarbigeWelt wrote: Tue Nov 19, 2019 10:46 am Please consider AMD ROCm, HIP.
It works only on Linux, it doesn't support your GPU (i.e. Navi) or other vendor GPUs ... it is a joke :roll: