10 ms·

Zluda: CUDA on Intel GPUs

261 points by fho 6y ago

keyle 6y ago
On top of HN... I get excited to use it with Blender then scroll through a plethora of "awesomeness" text to find this > Warning: this is a very incomplete proof of concept. It's probably not going to work with your application. ZLUDA currently works only with applications which use CUDA Driver API or statically-linked CUDA Runtime API - dynamically-linked CUDA Runtime API is not supported at all. Common man. You can't call it a drop in replacement if it's an incomplete proof of concept.
- JosephRedfern 6y ago
  I don’t think it’s unfair to call it a drop in replacement, though the current limitations should perhaps be caveated a little more clearly. I think calling it a drop in replacement highlights that the aim of Zluda is to not require recompilation of the software being run. Maybe “Proof of concept drop in replacement” would be a better description?
- syspec 6y ago
  That's the goal, even if not there yet
  - bottled_poe 6y ago
    What’s does this mean? Is the statement in the article true or not?
- rvz 6y ago
  > Common man. You can't call it a drop in replacement if it's an incomplete proof of concept. I was nearly put off by that but maybe it should be given a chance with some funding or what not. All great and interesting things come from proof of concepts, that actually work. At least it isn't vapourware. Unlike some 'projects' I see on GitHub.
  - rvz 6y ago
    Downvoters: So this 'proof of concept' on GitHub is in fact some how 'vapourware', and it shows an empty repository with zero functioning working code? I'm looking at the same repository as everyone else in this HN post. Literally the top comment is even suggesting that Intel could be interested in funding this, so surely it deserves a chance with some backing, even if it is 'incomplete'. Care to explain the downvotes?
    - deleted 6y ago
      [deleted]
dogma1138 6y ago
How does this work with CUDA libraries? Does it has an implementation of the standard libraries at least?
maleadt 6y ago
Impressive! The PTX to SPIR-V compiler must have been quite a bit of work; what's the coverage of the ISA like? With oneAPI I had hoped to get the inverse, a oneAPI implementation for NVIDIA hardware, but I don't think the CUDA driver API is low-level enough to do so (e.g. explicit vs global contexts). And yes, I know of Codeplay's implementation of DPC++ for NVIDIA GPUs, but that doesn't implement oneAPI Level0 APIs so is not usable for other languages.
- rodburns 6y ago
  I'm from Codeplay and I am not sure about what you mean from your comment about Level0. Intel have developed a back-end for DPC++ that supports Intel processors through OpenCL and SPIR-V. Codeplay has implemented a back-end that supports Nvidia processors by using PTX instructions in the same way that native CUDA code does. PTX is the equivalent to SPIR for Nvidia processors. Maybe I am misunderstanding so apologies if that is the case.
sciprojguy 6y ago
I'm stoked for this to be usable on things like PyTorch.
- rrss 6y ago
  The author has a comment here describing what that would take: https://github.com/vosen/ZLUDA/issues/17#issuecomment-735403167 https://github.com/vosen/ZLUDA/issues/17#issuecomment-735403.... tl;dr: someone would need to re-implement cuDNN
einpoklum 6y ago
Very nice! I look forward to trying this out. There a few issues which come to mid though: 1. How do these benchmark results compare to writing x64_64 implementations directly? That is, is it enough to reach OpenCL-level performance? 2. What about if I want to use both a CPU and and a GPU? It seems that would not be supported, as this library produces a `libcuda.so`. 3. What about AMD chips? 4. The README says: > Authors of CUDA benchmarks used CUDA functions atomicInc > and atomicDec which have direct hardware support on NVIDIA > cards, but no hardware support on Intel cards. They have > to be emulated in software, which limits performance is there really no support, not even in the near future, for atomic increment on Intel chips? 5. This is all written in Rust. It's a bit fishy to me for a C library to be implemented in Rust, though maybe I'm just a little prejudiced. 6. Where is the documentation of the semantic differences between proper CUDA and ZLUDA? e.g. - what do streams do? How do events work? etc.
- johnnycerberus 6y ago
  To be fair I have the same feeling about Rust. C++ is the language positioned for high performance computing, almost everything that screams HPC is in C++. We already have problems in our company modifying some old Fortran libraries that are called from C++ and in the future God knows what Rust or Zig training we will require for basically no upside for HPC. But if safety would be my concern, I would totally look towards Rust. Or hopefully, Julia will save the day.
makapuf 6y ago
Does the same exist with amd ? Sorry for asking maybe the obvious but could it be made?
- tomash 6y ago
  kinda: https://www.reddit.com/r/Amd/comments/hp88jb/is_there_any_api_equivalent_to_cuda_by_amd_that/fxnssbi/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/Amd/comments/hp88jb/is_there_any_ap...
  - my123 6y ago
    My opinion about the subject: AMD actually does not care about GPU compute on customer hardware. If they did they would not have: - Have had support for Linux only, with no ROCm on Windows - Have made ROCm as a GPU-specific targeted process, there's no IR like PTX to make your current *binary* run on future GPU generations - Having dropped support for GCN2/3 (https://github.com/RadeonOpenCompute/ROCm/issues/1353#issuecomment-753772733 https://github.com/RadeonOpenCompute/ROCm/issues/1353#issuec...) making the _only_ supported customer GPU generation Vega, with no support for RDNA/RDNA2. They obviously don't care about the market as they should, despite anything they might or they might not say. Nothing to see here... It's only and solely their own fault that NVIDIA is the only option. Intel so far has a much more competent strategy around GPU computing, and might prove to be an actual competitor. I've written off AMD as a possible competitor to NVIDIA for GPU computing a long time ago.
    - dogma1138 6y ago
      They dropped GCN2/3 support before ROCm was even anywhere near production ready but the biggest issue is the lack of cross platform as you mentioned you can’t even use it in Windows containers and also that they never even attempted to support APUs. Intel not only has better OpenCL support but will come out out of the gate with OneAPI that will support all Intel GPUs this means productivity applications could use it wether it’s for a laptop or for a future productivity workstation with an Intel discrete GPU. It’s pretty much impossible to buy a laptop with an AMD GPU and run ROCm on it, even the discrete cards are not officially supported and since the ROCm binaries are hardware specific without official support things tend to be even more broken than what they are now. I really can’t understand how AMD could cock it up so badly.
martini333 6y ago
Eth?
- krick 6y ago
  You wouldn't care about GPU API when mining crypto. You just need more GPUs. There's nothing complicated about the software you need for that.
anovikov 6y ago
can i use ffmpeg with h264_evenc to encode videos with it?
- anovikov 6y ago
  what's wrong about my question? yes i know it makes little sense because every motherboard with Intel GPU probably has a CPU with QuickSync Video support and that will most certainly work better for encoding (h264_qsv), but in theory?
- wmf 6y ago
  Video encoding uses different hardware and different APIs than GPGPU. FFMPEG can use Intel, AMD, and Nvidia hardware encoding; see https://trac.ffmpeg.org/wiki/HWAccelIntro https://trac.ffmpeg.org/wiki/HWAccelIntro
  - anovikov 6y ago
    Yeah i know, but NVENC is based on CUDA, that is, it doesn't interact with the GPU (NVIDIA in that case) directly, it works with CUDA library. So if Zluda is a CUDA compatibility layer for Intel GPUs, why not?
exhilaration 6y ago
Upvoting so someone from Intel sees it and hires these devs to make this actually happen. CUDA absolutely dominates, it would be a game changer to have it work with another GPU platform.
- k_sze 6y ago
  I think the correct way to solve it is to make something competitive for Vulkan. Intel, AMD, and maybe ARM should really cooperate on that front.
varispeed 6y ago
This looks like something Intel should be paying good money for, but I feel like they are just going to "embrace" open source and snatch it without giving a penny to the author.
- numlock86 6y ago
  You make it sound like that's an issue with Intel while the license is to blame.
  - krick 6y ago
    So, basically this project is illegal and waiting to be removed from Github then?
    - barkingcat 6y ago
      yes. I am not a lawyer but nvidia's lawyers would be interested I bet.
    - qiqitori 6y ago
      (IANAL.) Without looking into the CUDA licenses (who knows, they might even expressly allow this kind of thing, but seems pretty unlikely to me), I'd expect this to be a case of whether "APIs are copyrightable" or not, same as the famous and sort of still ongoing https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... The US courts said "yes" in this case (note: 100% stupid IMO), but I'm not confident that nVidia'd have an easy win if they decided to sue the developer, and I'm also relatively sure they wouldn't send a DMCA request at this stage (and that if they did, their request would probably be reviewed harder than normal).
      - jcranmer 6y ago
        That's not the most accurate summary of Google v Oracle. The case has been tried twice, Google has been found in the clear twice at the district court by the jury, and the Court of Appeals for the Federal Circuit has twice overturned the jury result, and the case is now at the Supreme Court awaiting a decision as to whether or not CAFC's decision is off it's rocker. It is not usual for CAFC to hear copyright disputes; that it was appealed to CAFC instead of the 9th Circuit is because there was a patent claim at one point, and CAFC should have followed 9th Circuit precedent on the matter. Google contends that 9th Circuit precedent holds that the API is not copyrightable, which means that CAFC erred in ignoring precedent. Most software companies ultimately agree with Google here, not Oracle: it's telling that most of the amici who side with Oracle are not software companies but media publishers (e.g., MPAA, RIAA).
xena 6y ago
Yes please take business away from Nvidia and AMD. I just want to buy a GPU.
pjmlp 6y ago
> Is ZLUDA a drop-in replacement for CUDA? > > Yes, but certain applications use CUDA in ways which make it incompatible with ZLUDA I fail to see how that is a drop-down replacement. Plus apparently it doesn't support the polyglot CUDA ecosystem.
villgax 6y ago
Intel should back the crap outta this project/dev
teleforce 6y ago
Fun facts, now even the latest lower end Intel's CPUs (Atom, Pentium, Celeron) will feature the much improved Gen 11 iGPU over the last generation Intel's built in GPU [1]. The latest iGPU supports more than 1 TFLOP in GPU performance. This is apparently more than the performance of two years old Nvidia GeForce GT 1030. [1]https://www.notebookcheck.net/Intel-s-Elkhart-Lake-SoC-will-feature-a-Gen11-iGPU.414181.0.html https://www.notebookcheck.net/Intel-s-Elkhart-Lake-SoC-will-...
- TomVDB 6y ago
  >This is apparently more than the performance of two years old Nvidia GeForce GT 1030. Almost 4 years old... https://www.techpowerup.com/gpu-specs/geforce-gt-1030.c2954 https://www.techpowerup.com/gpu-specs/geforce-gt-1030.c2954 "The GeForce GT 1030 is an entry-level graphics card by NVIDIA, launched in May 2017."
  - teleforce 6y ago
    My bad, when iGPU were first announced, GT 1030 is barely two years old as mentioned in the article. Anyway having iGPU inside an entry level Intel's CPU with a potential of 32 GB of RAM is amazing. The performance is probably not that far off from my old high end Asus ROG gaming laptop that I bought in 2014 with Nvidia GTX 700 series GPU. The laptop with the entry level iGPU will probably cost less than 20% of the original ROG laptop but now can supports up to three 4K monitors! If Asus can resurrect their infamous Netbook series laptop or cheap laptop lines with these new entry level CPUs with iGPU I bet it can sell them like hot cakes. [1]https://rog.asus.com/articles/g-series-gaming-laptops/asus-introduces-the-republic-of-gamers-g750-laptop/ https://rog.asus.com/articles/g-series-gaming-laptops/asus-i...
macksd 6y ago
Love this concept and hope this does well or something like it becomes a de facto standard. There's an explosion of software using GPUs. In the DL space alone, PyTorch and TensorFlow and many frameworks that compete with them, plug-in to them, etc. There's also an explosion of DL hardware coming. We have NVIDIA's whole product line, competing GPUs, TPUs, Inferentia, a bunch of start ups... That compatibility matrix is going to be insane. You need a good integration layer between them. If everyone can support CUDA, great. But there's also OpenCL and other competing standards. They're all going to have some performance trade-offs, but some of that must be worth it to keep some semblance of a common framework, otherwise small and new players don't stand much of a chance.
- tachyonbeam 6y ago
  I wish PyTorch would utilize CPUs more effectively out of the box. The last time I tried to run some DNN training on CPU (last summer), I was disappointed to find that only one single core was used on my Ryzen machine. Yes, GPUs don't have as much memory bandwidth or compute as GPUs, but this is still leaving a lot of performance on the table.
  - rrss 6y ago
    pytorch can use more than one core.
wmu 6y ago
Trivia: the Polish word "cuda" means "miracles", "zluda" ("złuda") means "a delusion". Nice pun.
- antjanus 6y ago
  I'm Czech and under the dialect where I grew up, "Zluda" could be translated to "evil person/monster" or "mischievous person/monster". Growing up, people sometimes called their kids "zludy" (plural of "zluda" in my language) -- or trouble-makers.
  - hackyhacky 6y ago
    Interesting. Possibly a variant of the standard word zrůda?
    - antjanus 6y ago
      Yeah, could be! I grew up close to the polish/slovak/czech border. I bet some of those words got mixed together.
- neolog 6y ago
  Off topic...I heard that a common Polish swear-word is "cholera", because the disease is so bad. Is that true?
  - ols 6y ago
    It is.
  - aphroz 6y ago
    Same in Dutch, they use disease names such as cancer or typhus as bad words
jonplackett 6y ago
So how come this still can’t be done with AMD GPUs?
- vetinari 6y ago
  See this comment below: https://news.ycombinator.com/item?id=26285380 https://news.ycombinator.com/item?id=26285380
- deleted 6y ago
  [deleted]
Abishek_Muthian 6y ago
Excellent effort. Nvidia has become defacto GPGPU hardware vendor due to CUDA, but I wish it was OpenCL or other general API instead. Even Raspberry Pi's VideoCore has OpenCL support[1]. But a look at HW Acceleration support table at FFmpeg[2] shows why GPGPU Platform API is such a mess. But performance benefits are incredible, using VAAPI for FFmpeg to encode 1080p 2560x1080 screen capture at 60fps reduces CPU usage from 90% to 10% on a old corei5 with intel HD 3000; An old laptop could be perfectly used as an encoding machine for streaming just by using HW Acceleration. What's funny is that the laptop also has Radeon HD 6490M with 1GB GDDR5 dedicated memory and it's not supported by VAAPI for encoding! GPGPU API/Platform Support are astonishingly messy. [1]https://github.com/doe300/VC4CL https://github.com/doe300/VC4CL [2]https://trac.ffmpeg.org/wiki/HWAccelIntro https://trac.ffmpeg.org/wiki/HWAccelIntro
- zamadatix 6y ago
  GPU accelerated video encoding/decoding is done largely via special fixed function hardware not GPGPU so there really isn't a relation between the links and the statements. The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. The HD 7000 series introduced it to the family. https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_Feature_Matrix https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_F...
  - marmaduke 6y ago
    > The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. Doesn’t this prove the broader point that GPGPU cross platform would benefit everyone? A new codec is written.. and everyone gets to use it not just those with fixed function support.
    - zamadatix 6y ago
      No, it proves fixed function hardware outperforms general purpose hardware for the task it's made for. Without the fixed function hardware the GPU is worse suited for the task than a general purpose CPU.
trevortheblack 6y ago
I was working at Intel on integrated graphics less than a year ago. Geekbench could, at best, be described as a fine benchmark. But it's pretty terrible in a bunch of respects. I would love to see more benchmarks run through with this.
Const-me 6y ago
> Authors of CUDA benchmarks used CUDA functions atomicInc and atomicDec which have direct hardware support on NVIDIA cards, but no hardware support on Intel cards. Then how does InterlockedAdd HLSL intrinsic works on Intel? https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/interlockedadd https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/...
- deleted 6y ago
  [deleted]
en4bz 6y ago
> Tying to the previous point, currently ZLUDA does not support asynchronous execution. This gives us an unfair advantage in a benchmark like GeekBench. GeekBench exclusively uses CUDA synchronous APIs Any "professional" application solely use async APIs so while these numbers may look impressive something like tensorflow or pytorch would either not run or be incredibly slow.

261 points by fho 6y ago

On top of HN... I get excited to use it with Blender then scroll through a plethora of "awesomeness" text to find this > Warning: this is a very incomplete proof of concept. It's probably not going to work with your application. ZLUDA currently works only with applications which use CUDA Driver API or statically-linked CUDA Runtime API - dynamically-linked CUDA Runtime API is not supported at all. Common man. You can't call it a drop in replacement if it's an incomplete proof of concept.

JosephRedfern 6y ago
I don’t think it’s unfair to call it a drop in replacement, though the current limitations should perhaps be caveated a little more clearly. I think calling it a drop in replacement highlights that the aim of Zluda is to not require recompilation of the software being run. Maybe “Proof of concept drop in replacement” would be a better description?
syspec 6y ago
That's the goal, even if not there yet
- bottled_poe 6y ago
  What’s does this mean? Is the statement in the article true or not?
rvz 6y ago
> Common man. You can't call it a drop in replacement if it's an incomplete proof of concept. I was nearly put off by that but maybe it should be given a chance with some funding or what not. All great and interesting things come from proof of concepts, that actually work. At least it isn't vapourware. Unlike some 'projects' I see on GitHub.
- rvz 6y ago
  Downvoters: So this 'proof of concept' on GitHub is in fact some how 'vapourware', and it shows an empty repository with zero functioning working code? I'm looking at the same repository as everyone else in this HN post. Literally the top comment is even suggesting that Intel could be interested in funding this, so surely it deserves a chance with some backing, even if it is 'incomplete'. Care to explain the downvotes?
  - deleted 6y ago
    [deleted]

dogma1138 6y ago

How does this work with CUDA libraries? Does it has an implementation of the standard libraries at least?

maleadt 6y ago

Impressive! The PTX to SPIR-V compiler must have been quite a bit of work; what's the coverage of the ISA like? With oneAPI I had hoped to get the inverse, a oneAPI implementation for NVIDIA hardware, but I don't think the CUDA driver API is low-level enough to do so (e.g. explicit vs global contexts). And yes, I know of Codeplay's implementation of DPC++ for NVIDIA GPUs, but that doesn't implement oneAPI Level0 APIs so is not usable for other languages.

rodburns 6y ago
I'm from Codeplay and I am not sure about what you mean from your comment about Level0. Intel have developed a back-end for DPC++ that supports Intel processors through OpenCL and SPIR-V. Codeplay has implemented a back-end that supports Nvidia processors by using PTX instructions in the same way that native CUDA code does. PTX is the equivalent to SPIR for Nvidia processors. Maybe I am misunderstanding so apologies if that is the case.

sciprojguy 6y ago

I'm stoked for this to be usable on things like PyTorch.

rrss 6y ago
The author has a comment here describing what that would take: https://github.com/vosen/ZLUDA/issues/17#issuecomment-735403167 https://github.com/vosen/ZLUDA/issues/17#issuecomment-735403.... tl;dr: someone would need to re-implement cuDNN

einpoklum 6y ago

Very nice! I look forward to trying this out. There a few issues which come to mid though: 1. How do these benchmark results compare to writing x64_64 implementations directly? That is, is it enough to reach OpenCL-level performance? 2. What about if I want to use both a CPU and and a GPU? It seems that would not be supported, as this library produces a `libcuda.so`. 3. What about AMD chips? 4. The README says: > Authors of CUDA benchmarks used CUDA functions atomicInc > and atomicDec which have direct hardware support on NVIDIA > cards, but no hardware support on Intel cards. They have > to be emulated in software, which limits performance is there really no support, not even in the near future, for atomic increment on Intel chips? 5. This is all written in Rust. It's a bit fishy to me for a C library to be implemented in Rust, though maybe I'm just a little prejudiced. 6. Where is the documentation of the semantic differences between proper CUDA and ZLUDA? e.g. - what do streams do? How do events work? etc.

johnnycerberus 6y ago
To be fair I have the same feeling about Rust. C++ is the language positioned for high performance computing, almost everything that screams HPC is in C++. We already have problems in our company modifying some old Fortran libraries that are called from C++ and in the future God knows what Rust or Zig training we will require for basically no upside for HPC. But if safety would be my concern, I would totally look towards Rust. Or hopefully, Julia will save the day.

makapuf 6y ago

Does the same exist with amd ? Sorry for asking maybe the obvious but could it be made?

tomash 6y ago
kinda: https://www.reddit.com/r/Amd/comments/hp88jb/is_there_any_api_equivalent_to_cuda_by_amd_that/fxnssbi/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/Amd/comments/hp88jb/is_there_any_ap...
- my123 6y ago
  My opinion about the subject: AMD actually does not care about GPU compute on customer hardware. If they did they would not have: - Have had support for Linux only, with no ROCm on Windows - Have made ROCm as a GPU-specific targeted process, there's no IR like PTX to make your current *binary* run on future GPU generations - Having dropped support for GCN2/3 (https://github.com/RadeonOpenCompute/ROCm/issues/1353#issuecomment-753772733 https://github.com/RadeonOpenCompute/ROCm/issues/1353#issuec...) making the _only_ supported customer GPU generation Vega, with no support for RDNA/RDNA2. They obviously don't care about the market as they should, despite anything they might or they might not say. Nothing to see here... It's only and solely their own fault that NVIDIA is the only option. Intel so far has a much more competent strategy around GPU computing, and might prove to be an actual competitor. I've written off AMD as a possible competitor to NVIDIA for GPU computing a long time ago.
  - dogma1138 6y ago
    They dropped GCN2/3 support before ROCm was even anywhere near production ready but the biggest issue is the lack of cross platform as you mentioned you can’t even use it in Windows containers and also that they never even attempted to support APUs. Intel not only has better OpenCL support but will come out out of the gate with OneAPI that will support all Intel GPUs this means productivity applications could use it wether it’s for a laptop or for a future productivity workstation with an Intel discrete GPU. It’s pretty much impossible to buy a laptop with an AMD GPU and run ROCm on it, even the discrete cards are not officially supported and since the ROCm binaries are hardware specific without official support things tend to be even more broken than what they are now. I really can’t understand how AMD could cock it up so badly.

martini333 6y ago

Eth?

krick 6y ago
You wouldn't care about GPU API when mining crypto. You just need more GPUs. There's nothing complicated about the software you need for that.

anovikov 6y ago

can i use ffmpeg with h264_evenc to encode videos with it?

anovikov 6y ago
what's wrong about my question? yes i know it makes little sense because every motherboard with Intel GPU probably has a CPU with QuickSync Video support and that will most certainly work better for encoding (h264_qsv), but in theory?
wmf 6y ago
Video encoding uses different hardware and different APIs than GPGPU. FFMPEG can use Intel, AMD, and Nvidia hardware encoding; see https://trac.ffmpeg.org/wiki/HWAccelIntro https://trac.ffmpeg.org/wiki/HWAccelIntro
- anovikov 6y ago
  Yeah i know, but NVENC is based on CUDA, that is, it doesn't interact with the GPU (NVIDIA in that case) directly, it works with CUDA library. So if Zluda is a CUDA compatibility layer for Intel GPUs, why not?

exhilaration 6y ago

Upvoting so someone from Intel sees it and hires these devs to make this actually happen. CUDA absolutely dominates, it would be a game changer to have it work with another GPU platform.

k_sze 6y ago
I think the correct way to solve it is to make something competitive for Vulkan. Intel, AMD, and maybe ARM should really cooperate on that front.

varispeed 6y ago

This looks like something Intel should be paying good money for, but I feel like they are just going to "embrace" open source and snatch it without giving a penny to the author.

numlock86 6y ago
You make it sound like that's an issue with Intel while the license is to blame.
- krick 6y ago
  So, basically this project is illegal and waiting to be removed from Github then?
  - barkingcat 6y ago
    yes. I am not a lawyer but nvidia's lawyers would be interested I bet.
  - qiqitori 6y ago
    (IANAL.) Without looking into the CUDA licenses (who knows, they might even expressly allow this kind of thing, but seems pretty unlikely to me), I'd expect this to be a case of whether "APIs are copyrightable" or not, same as the famous and sort of still ongoing https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... The US courts said "yes" in this case (note: 100% stupid IMO), but I'm not confident that nVidia'd have an easy win if they decided to sue the developer, and I'm also relatively sure they wouldn't send a DMCA request at this stage (and that if they did, their request would probably be reviewed harder than normal).
    - jcranmer 6y ago
      That's not the most accurate summary of Google v Oracle. The case has been tried twice, Google has been found in the clear twice at the district court by the jury, and the Court of Appeals for the Federal Circuit has twice overturned the jury result, and the case is now at the Supreme Court awaiting a decision as to whether or not CAFC's decision is off it's rocker. It is not usual for CAFC to hear copyright disputes; that it was appealed to CAFC instead of the 9th Circuit is because there was a patent claim at one point, and CAFC should have followed 9th Circuit precedent on the matter. Google contends that 9th Circuit precedent holds that the API is not copyrightable, which means that CAFC erred in ignoring precedent. Most software companies ultimately agree with Google here, not Oracle: it's telling that most of the amici who side with Oracle are not software companies but media publishers (e.g., MPAA, RIAA).

xena 6y ago

Yes please take business away from Nvidia and AMD. I just want to buy a GPU.

pjmlp 6y ago

> Is ZLUDA a drop-in replacement for CUDA? > > Yes, but certain applications use CUDA in ways which make it incompatible with ZLUDA I fail to see how that is a drop-down replacement. Plus apparently it doesn't support the polyglot CUDA ecosystem.

villgax 6y ago

Intel should back the crap outta this project/dev

teleforce 6y ago

Fun facts, now even the latest lower end Intel's CPUs (Atom, Pentium, Celeron) will feature the much improved Gen 11 iGPU over the last generation Intel's built in GPU [1]. The latest iGPU supports more than 1 TFLOP in GPU performance. This is apparently more than the performance of two years old Nvidia GeForce GT 1030. [1]https://www.notebookcheck.net/Intel-s-Elkhart-Lake-SoC-will-feature-a-Gen11-iGPU.414181.0.html https://www.notebookcheck.net/Intel-s-Elkhart-Lake-SoC-will-...

TomVDB 6y ago
>This is apparently more than the performance of two years old Nvidia GeForce GT 1030. Almost 4 years old... https://www.techpowerup.com/gpu-specs/geforce-gt-1030.c2954 https://www.techpowerup.com/gpu-specs/geforce-gt-1030.c2954 "The GeForce GT 1030 is an entry-level graphics card by NVIDIA, launched in May 2017."
- teleforce 6y ago
  My bad, when iGPU were first announced, GT 1030 is barely two years old as mentioned in the article. Anyway having iGPU inside an entry level Intel's CPU with a potential of 32 GB of RAM is amazing. The performance is probably not that far off from my old high end Asus ROG gaming laptop that I bought in 2014 with Nvidia GTX 700 series GPU. The laptop with the entry level iGPU will probably cost less than 20% of the original ROG laptop but now can supports up to three 4K monitors! If Asus can resurrect their infamous Netbook series laptop or cheap laptop lines with these new entry level CPUs with iGPU I bet it can sell them like hot cakes. [1]https://rog.asus.com/articles/g-series-gaming-laptops/asus-introduces-the-republic-of-gamers-g750-laptop/ https://rog.asus.com/articles/g-series-gaming-laptops/asus-i...

macksd 6y ago

Love this concept and hope this does well or something like it becomes a de facto standard. There's an explosion of software using GPUs. In the DL space alone, PyTorch and TensorFlow and many frameworks that compete with them, plug-in to them, etc. There's also an explosion of DL hardware coming. We have NVIDIA's whole product line, competing GPUs, TPUs, Inferentia, a bunch of start ups... That compatibility matrix is going to be insane. You need a good integration layer between them. If everyone can support CUDA, great. But there's also OpenCL and other competing standards. They're all going to have some performance trade-offs, but some of that must be worth it to keep some semblance of a common framework, otherwise small and new players don't stand much of a chance.

tachyonbeam 6y ago
I wish PyTorch would utilize CPUs more effectively out of the box. The last time I tried to run some DNN training on CPU (last summer), I was disappointed to find that only one single core was used on my Ryzen machine. Yes, GPUs don't have as much memory bandwidth or compute as GPUs, but this is still leaving a lot of performance on the table.
- rrss 6y ago
  pytorch can use more than one core.

wmu 6y ago

Trivia: the Polish word "cuda" means "miracles", "zluda" ("złuda") means "a delusion". Nice pun.

antjanus 6y ago
I'm Czech and under the dialect where I grew up, "Zluda" could be translated to "evil person/monster" or "mischievous person/monster". Growing up, people sometimes called their kids "zludy" (plural of "zluda" in my language) -- or trouble-makers.
- hackyhacky 6y ago
  Interesting. Possibly a variant of the standard word zrůda?
  - antjanus 6y ago
    Yeah, could be! I grew up close to the polish/slovak/czech border. I bet some of those words got mixed together.
neolog 6y ago
Off topic...I heard that a common Polish swear-word is "cholera", because the disease is so bad. Is that true?
- ols 6y ago
  It is.
- aphroz 6y ago
  Same in Dutch, they use disease names such as cancer or typhus as bad words

jonplackett 6y ago

So how come this still can’t be done with AMD GPUs?

vetinari 6y ago
See this comment below: https://news.ycombinator.com/item?id=26285380 https://news.ycombinator.com/item?id=26285380
deleted 6y ago
[deleted]

Abishek_Muthian 6y ago

Excellent effort. Nvidia has become defacto GPGPU hardware vendor due to CUDA, but I wish it was OpenCL or other general API instead. Even Raspberry Pi's VideoCore has OpenCL support[1]. But a look at HW Acceleration support table at FFmpeg[2] shows why GPGPU Platform API is such a mess. But performance benefits are incredible, using VAAPI for FFmpeg to encode 1080p 2560x1080 screen capture at 60fps reduces CPU usage from 90% to 10% on a old corei5 with intel HD 3000; An old laptop could be perfectly used as an encoding machine for streaming just by using HW Acceleration. What's funny is that the laptop also has Radeon HD 6490M with 1GB GDDR5 dedicated memory and it's not supported by VAAPI for encoding! GPGPU API/Platform Support are astonishingly messy. [1]https://github.com/doe300/VC4CL https://github.com/doe300/VC4CL [2]https://trac.ffmpeg.org/wiki/HWAccelIntro https://trac.ffmpeg.org/wiki/HWAccelIntro

zamadatix 6y ago
GPU accelerated video encoding/decoding is done largely via special fixed function hardware not GPGPU so there really isn't a relation between the links and the statements. The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. The HD 7000 series introduced it to the family. https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_Feature_Matrix https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_F...
- marmaduke 6y ago
  > The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. Doesn’t this prove the broader point that GPGPU cross platform would benefit everyone? A new codec is written.. and everyone gets to use it not just those with fixed function support.
  - zamadatix 6y ago
    No, it proves fixed function hardware outperforms general purpose hardware for the task it's made for. Without the fixed function hardware the GPU is worse suited for the task than a general purpose CPU.

trevortheblack 6y ago

I was working at Intel on integrated graphics less than a year ago. Geekbench could, at best, be described as a fine benchmark. But it's pretty terrible in a bunch of respects. I would love to see more benchmarks run through with this.

Const-me 6y ago

> Authors of CUDA benchmarks used CUDA functions atomicInc and atomicDec which have direct hardware support on NVIDIA cards, but no hardware support on Intel cards. Then how does InterlockedAdd HLSL intrinsic works on Intel? https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/interlockedadd https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/...

deleted 6y ago
[deleted]

en4bz 6y ago

> Tying to the previous point, currently ZLUDA does not support asynchronous execution. This gives us an unfair advantage in a benchmark like GeekBench. GeekBench exclusively uses CUDA synchronous APIs Any "professional" application solely use async APIs so while these numbers may look impressive something like tensorflow or pytorch would either not run or be incredibly slow.