Hot answers tagged

25

It's essentially because not all GPUs can support function calls—and even if they can, function calls may be quite slow or have limitations such as a very small stack depth. Shader code and GPU compute code may appear to have function calls all over the place, but under normal circumstances they're all 100% inlined by the compiler. The machine code ...


7

It's not quite correct, today, to think of compute shaders as being "in the shader pipeline" in the same sense that your vertex and fragment shaders are literally hooked up into a pipeline. Compute shaders are not "hooked up" to anything currently, cannot drive rasterization, or directly consume the outputs of rasterization. What it allows you to do, ...


4

To first clear your confusion around the terms: GPGPU stands for General Purpose computing on GPUs CUDA is the specific NVIDIA API to perform GPGPU only on their hardware OpenGL is a graphics specific API and is vendor independent OpenCL is a parallel programming compute API and is vendor independent Compute Shaders are a way to perform general purpose ...


3

I should warn you that I don't really know anything about linux or programming or device drivers, but I had your exact problem once. It could be a udev rule problem. Your usergroup might not have permission to write to the gpu device or whatever libOpenCL.so does. Does $ sudo clinfo find the gpu? Your program might not be using the right opencl library. I ...


2

Compute queues in general don't necessarily mean you can now do 2x dispatches in parallel. A single queue that fully saturates the compute units will have better throughput. Multiple queues are useful if one queue consumes less resources (shared memory or registers), then secondary queues can then overlap on the same compute unit. For real-time rendering ...


2

Are there algorithms that cannot be implemented this way and have to be implemented in OpenCL, and if so, how do I know if my algorithm is one of them? Yes. Generally scatter-gather algorithms work poorly in OpenGL as the data locality is poor. When you have to grab bits from all over the input image for each output pixel, it's going to be slow or nearly ...


2

In short: All of it can benefit from OpenCL. Path tracing is done by taking many individual ray samples from a scene and combining them into a final image. As the number of samples increase, so does the quality of the resulting image. If you are doing regular path tracing (not photon mapping or bidirectional path tracing or anything like that), each ...


2

OpenCL isn't really a drawing API, it's designed for doing compute workloads across different devices, not necessarily GPUs. You can certainly write a kernel that renders to a texture in OpenCL, and have this texture be available to Open GL or D3D. AFAIK, though, you wouldn't have access to the fixed-function hardware like rasterization, attribute ...


1

In order to pass data to the device side, in OpenCL you must create the sphere structure on the device as well (that is in the kernel). So you first create your structures as classes or structs on the CPU. The variables in the structs should be of cl_* datatypes. OpenCL provides typedefs for all primitive data types. Then create these structures on the GPU ...


1

I too could not see my GPU through clinfo. The fix for me was disabling Secure Boot in the BIOS which did not let the Ubuntu kernel load DKMS code. There was even a ncurses warning after installing the driver, in my case AMDGPU PRO 16.60 on Ubuntu 16.10. I hope this helps!


Only top voted, non community-wiki answers of a minimum length are eligible