- #VRAY RT OPENCL BENCHMARK DRIVERS#
- #VRAY RT OPENCL BENCHMARK SOFTWARE#
- #VRAY RT OPENCL BENCHMARK PC#
I do however recognize that solving this issue is not something that can be done in a few weeks work, however the improvements AMD have shown in the recent drivers for GCN hardware would appear that they have put in a fair amount of effort, and maybe only a few changes (such as the Micro Kernels just added to LuxCore) could be that last step.
#VRAY RT OPENCL BENCHMARK PC#
I would say the percentage of 3D artists that have $200 or greater GPU’s would be far higher than the percentage of all PC users that have a > $200 GPU. as on of LuxRender developers, please, continue to not fix this problem, it is very healthy for Lux project being the only open-source/free OpenCL renderer In my opinion is that is 50% AMD problem and 50% BF problem.
The large majority of people here seems to think that it is a 100% AMD fault and it requires actions only from AMD side. We can probably arguing on this point for a long time but I think the the core of the discussion here is: Cycles doesn’t work on AMD GPUs, what actions are required to fix this problem ? And, most importantly, who has to fix the problem ? It is also a very short list: “renderers that actually are driven by market forces” seems to mostly work on CPUs instead of GPUs. If you take away Iray (owned by NVIDIA), it is 2 OpenCL-only, 1 CUDA-only and Cycles (nearly CUDA-only ?). Now try to enumerate GPUs renderers: VRay RT (OpenCL), Octane (CUDA), Iray (CUDA for obvious reasons), LuxRender (OpenCL), Blender Cycles (CUDA) … am I missing someone ? Just try to enumerate the CPU renderers available: it is a list including 20+ names. Why are most of the other renderers that actually are driven by market forces not supporting AMD? But again, this implementation is “not quite there yet”, just like all free OpenCL implementations, like MesaGL, like the free GPU drivers…ĭo you want to solve that problem? I’m all for it! But that’s not just Blender’s problem.Įven if I agreed that market forces applied to Blender (which I don’t), there would be no obligation.
#VRAY RT OPENCL BENCHMARK SOFTWARE#
It’s not something like an ISO standard.ĬUDA on the other hand is actually in large parts open-source software and there is at least one other free implementation. The Khronos Group is an industry consortium and it retains all the licensing rights for OpenCL. There is not a single capable non-proprietary implementation, nor is there a reference implementation. We’re talking about a speedup for people who have the privilege of running 200$+ GPUs from a certain vendor.ĭon’t fool yourself into thinking OpenCL is not de-facto proprietary. Well alright, but what does that mean? I really have to stress this point: Nobody is being locked out of any functionality. to be more open etc…? I feel Blender’s development process appears less open than some other projects. But aren’t we meant to be those who don’t just go with supporting a platform, or in general often a propriety standard?Īs OSS software, shouldn’t we be different to those commercial companies.
0 kommentar(er)
