16 ms·
AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
- rasz 3y ago>For reasons unknown to me, AMD decided this year to discontinue funding the effort and not release it as any software product. classic AMD
- hd4 3y agohttps://github.com/vosen/ZLUDA https://github.com/vosen/ZLUDA - source
- fariszr 3y ago> after the CUDA back-end was around for years and after dropping OpenCL, Blender did add a Radeon HIP back-end... But the real kicker here is that using ZLUDA + CUDA back-end was slightly faster than the native Radeon HIP backend. This is absolutely crazy.
- toxik 3y agoIs AMD just a puppet org to placate antitrust fears? Why are they like this?
- deleted 3y ago[deleted]
- swozey 3y agoIs this really a theory? If so my $8 AMD stock from, 2015? is currently worth $176 so they should make more shell companies they're doing great. I guess that might answer my "Why would AMD find that having a CUDA competitor isn't a business case unless they couldn't do it or the cards underperformed significantly."
- kllrnohj 3y agoFor some reason AMD's GPU division continues to be run, well, horribly. The CPU division is crushing it, but the GPU division is comically bad. During the great GPU shortage AMD had multiple opportunities to capture chunks of the market and secure market share, increasing the priority for developers to acknowledge and target AMD's GPUs. What did they do instead? Not a goddamn thing, they followed Nvidia's pricing and managed to sell jack shit (like seriously the RX 580 is still the first AMD card to show up on the steam hardware survey). They're not going big enough dies at the top end to compete with nvidia for the halo, and they're refusing to undercut at the low end where nvidia's reputation for absurd pricing is at an all time high. AMD's GPU division is a clown show, it's impressively bad. Even though the hardware itself is fine they just can't stop either making terrible product launches, awful pricing strategies, or just brain dead software choices like shipping a feature that triggered anti-cheat, getting their customers predictably banned & angering game devs in the process And relevant to this discussion Nvidia's refusal to add VRAM to their lower end cards is a prime opportunity for AMD to go after the lower-end compute / AI interested crowd who will become the next generation software devs. What are they doing with this? Well, they're not making ROCm available to basically anyone, that's apparently the winning strategy. ROCm 6.0 only supports the 7900 XTX and the... Radeon VII. The weird one-off Vega 20 refresh. Of all the random cards to support, why the hell would you pick that one???
- swozey 3y ago> The (AMD) CPU division is crushing it I worked at a baremetal CDN with 60 pops and a few years ago we had to switch to AMD because of PCIE bandwidth over to our smartNICs and nvmeOF sort of things. We'd long hit limits on Intel before the Epyc stuff came out so we had to have more servers running than we wanted because we had to limit how much we did with one server to not hit the limits and cause everything to lock. And we were excited, not a single apprehension. Epyc crushed the server market, everyone is using them. Well, it's going ARM now but Epyc will still be around awhile.
- dehrmann 3y agoLike Mozilla?
- deleted 3y ago[deleted]
- wheybags 3y agoCannot understand why AMD would stop funding this. It seems like this should have a whole team allocated to it.
- otoburb 3y agoThey would always be at the mercy of NVIDIA's API. Without knowing the inner workings, perhaps a major concern with this approach is the need to implement on NVIDIA's schedule instead of AMD's which is a very reactive stance. This approach actually would make sense if AMD felt, like most of us perhaps, that the NVIDIA ecosystem is too entrenched, but perhaps they made the decision recently to discontinue funding because they (now?) feel otherwise.
- blagie 3y agoThey've been at mercy of Intel x86 APIs for a long time. Didn't kill them. What happens here is that the original vendor loses control of the API once there are multiple implementations. That's the best possible outcome for AMD. In either case, they have a limited window to be adopted, and that's more important. The abstraction layer here helps too. AMD code is !@#$%. If this were adopted, it makes it easier to fix things underneath. All that is a lot more important than a dream of disrupting CUDA.
- rubatuga 3y agox86 is not the same, the courts forced the release of x86 architecture to AMD during an antitrust lawsuit
- anon291 3y agoYou don't think the courts would force the opening of CUDA? Didn't a court already rule that API cannot be patented. I believe it was a Google case. As long as no implementation was stolen, the API itself is not able to be copyrighted. Here it is: https://arstechnica.com/tech-policy/2021/04/how-the-supreme-court-saved-the-software-industry-from-api-copyrights/ https://arstechnica.com/tech-policy/2021/04/how-the-supreme-...
- sam_goody 3y agoI don't really follow this, but isn't it a bad sign for ROCm that, for example, ZLUDA + Blender 4's CUDA back-end delivers better performance than the native Radeon HIP back-end?
- fariszr 3y agoIt really shows how neglected their software stack is, or at least how neglected this implementation is.
- whizzter 3y agoCould be that the CUDA backend has seen far more specialization optimizations whereas the seeingly fairly fresh HIP backend hasn't had as many developers looking at it, in the end a few more control instructions on the CPU side to go through the ZLUDA wrapper will be insignificant compared to all the time spent inside better optimized GPU kernels.
- KeplerBoy 3y agoSurely this can be attributed to Blender's HIP code just being suboptimal because nobody really cares about it. By extension nobody cares about it because performance is suboptimal. It's AMDs job to break that circle.
- mdre 3y agoI'd say it's even worse, since for rendering Optix is like 30% faster than CUDA. But that requires the tensor cores. At this point AMD is waaay behind hardware wise.
- btown 3y agoWhy would this not be AMD’s top priority among priorities? Someone recently likened the situation to an Iron Age where NVIDIA owns all the iron. And this sounds like AMD knowing about a new source of ore and not even being willing to sink a single engineer’s salary into exploration. My only guess is they have a parallel skunkworks working on the same thing, but in a way that they can keep it closed-source - that this was a hedge they think they no longer need, and they are missing the forest for the trees on the benefits of cross-pollination and open source ethos to their business.
- fariszr 3y agoAccording to the article, AMD seems to have pulled the plug on this as they think it will hinder ROCMv6 adoption, which still btw only supports two consumer cards out of their entire line up[1] 1. https://www.phoronix.com/news/AMD-ROCm-6.0-Released https://www.phoronix.com/news/AMD-ROCm-6.0-Released
- bhouston 3y agoAMD should have the funds to push both of these initiatives at once. If the ROCM team has political reasons to kill the competition, it is because they are scared it will succeed. I've seen this happen in big companies. But management at AMD should be above petty team politics and fund both because at the company level they do not care which solution wins in the end.
- imtringued 3y agoWhy would they be worried about people using their product? Some CUDA wrapper on top of ROCM isn't going to get them fired. It doesn't get rid of ROCM's function as a GPGPU driver.
- zer00eyz 3y agoIf your AMD you don't want to be compatible till you have a compelling feature of your own. Good enough CUDA + New feature x gives them leverage in the inevitable court battle(S) and patten sharing agreement that everyone wants to see. AMD' already stuck its toe in the water: new CPU's with their AI cores built in. If you can get a AM5 socket to run with 196 gigs, that's a large (all be it slow) model you can run.
- mdre 3y agoFun fact: ZLUDA means something like illusion/delusion/figment. Well played! (I see the main dev is from Poland.)
- Detrytus 3y agoYou should also mention that CUDA in Polish means "miracles" (plural).
- miduil 3y agoWow, this is great news. I really hope that the community will find ways to sustainable fund this project, being suddenly run a lot of innovative CUDA based projects on AMD GPUs is a big game-changer, especially because you don't have to deal with the poor state of nvidia on linux support.
- sam_goody 3y agoAside from the latest commit, there has been no activity for almost 3 years (latest code change on Feb 22, 2021). People are criticizing AMD for dropping this, but it makes sense to stop paying for development when the dev has stopped doing the work, no? And if he means that AMD stopped paying 3 years ago - well, that was before dinosaurs and ChatGPT, and alot has changed since then. https://github.com/vosen/ZLUDA/commits/v3 https://github.com/vosen/ZLUDA/commits/v3
- EspadaV9 3y agoPretty sure this was developed in private, but because AMD cancelled the contract he has been allowed to open source the code, and this is the "throw it over the fence" code dump.
- rrrix1 3y agoThis. 762 changed files with 252,017 additions and 39,027 deletions. https://github.com/vosen/ZLUDA/commit/1b9ba2b2333746c5e2b05a2bf24fa6ec3828dcdf https://github.com/vosen/ZLUDA/commit/1b9ba2b2333746c5e2b05a...
- Ambroisie 3y agoMy thinking is that the dev _did_ work on it for X amount of time, but as part of their contract is not allowed to share the _actual_ history of the repo, thus the massive code dumped in their "Nobody expects the Red Team" commit?
- rswail 3y agoHave a look at the latest commit and the level of change. Effectively the internal commits while he was working for AMD aren't in the repo, but the squashed commit contains all of the changes.
- michaellarabel 3y agoAs I wrote in the article, it was privately developed the past 2+ years while being contracted by AMD during that time... In a private GitHub repo. Now that he's able to make it public / open-source, he squashed all the changes into a clean new commit to make it public. The ZLUDA code from 3+ years ago was when he was experimenting with CUDA on Intel GPUs.
- AndrewKemendo 3y agoROCm is not spelled out anywhere in their documentation and the best answers in search come from Github and not AMD official documents "Radeon Open Compute Platform" https://github.com/ROCm/ROCm/issues/1628 https://github.com/ROCm/ROCm/issues/1628 And they wonder why they are losing. Branding absolutely matters.
- phh 3y agoI have no idea what CUDA stands for, and I live just fine without knowing it.
- moffkalast 3y agoCleverly Undermining Disorganized AMD
- rvnx 3y agoCountless Updates Developer Agony
- egorfine 3y agoThis is the right definition.
- hyperbovine 3y agoLost five hours of my life yesterday discovering the fact that "CUDA 12.3" != "CUDA 12.3 Update 2". (Yes, that's obvious, but not so obvious when your GPU applications submitted to a cluster start crashing randomly for no apparent reason.)
- smokel 3y agoCompute Unified Device Architecture [1] [1] https://en.wikipedia.org/wiki/CUDA https://en.wikipedia.org/wiki/CUDA
- alfalfasprout 3y agoCrap, updates destroyed (my) application
- pjmlp 3y agoSo polyglot programing workflows via PTX targeting are equally supported?
- eqvinox 3y agoKeeping my hopes curtailed until I see proper benchmarks…
- michalf6 3y agoZłuda roughly means "delusion" / "mirage" / "illusion" in Polish, given the author is called Andrzej Janik this may be a pun :)
- rvba 3y agoArguably one could also translate it as "something that will never happen". At the same time "cuda" could be translated as "wonders".
- hd4 3y agoThe interest in this thread tells me there are a lot of people who are not cool with the CUDA monopoly.
- smoldesu 3y agoThose people should have spoken up when their hardware manufacturers abandoned OpenCL. The industry set itself 5-10 years behind by ignoring open GPGPU compute drivers while Nvidia slowly built their empire. Just look at how long it's taken to re-impliment a fraction of the CUDA featureset on a small handful of hardware. CUDA shouldn't exist. We should have hardware manufacturers working together, using common APIs and standardizing instead of going for the throat. The further platforms drift apart, the more valuable Nvidia's vertical integration becomes.
- mnau 3y agoCommon API means being replaceable, fungible. There are no margins in that.
- smoldesu 3y agoCorrect. It's why the concept of 'proprietary UNIX' didn't survive long once program portability became an incentive.
- Avamander 3y agoIs my impression wrong, that people understood the need for OCL only after CUDA had already cornered and strangled the market?
- smoldesu 3y agoYou're mostly right. CUDA was a "sleeper product" that existed early-on but didn't see serious demand until later. OpenCL was Khronos Group's hedged bet against the success of CUDA; it was assumed that they would invest in it more as demand for GPGPU increased. After 10 years though, OpenCL wasn't really positioned to compete and CUDA was more fully-featured than ever. Adding insult to injury, OS manufacturers like Microsoft and Apple started to avoid standardized GPU libraries in favor of more insular native APIs. By the time demand for CUDA materialized, OpenCL had already been left for dead by most of the involved parties.
- cashsterling 3y agoI feel like AMD's senior executives all own a lot of nVIDIA stock.
- lambdaone 3y agoIt seems to me that AMD are crazy to stop funding this. CUDA-on-ROCm breaks NVIDIA's moat, and would also act as a disincentive for NVIDIA to make breaking changes to CUDA; what more could AMD want? When you're #1, you can go all-in on your own proprietary stack, knowing that network effects will drive your market share higher and higher for you for free. When you're #2, you need to follow de-facto standards and work on creating and following truly open ones, and try to compete on actual value, rather than rent-seeking. AMD of all companies should know this.
- RamRodification 3y ago> and would also act as a disincentive for NVIDIA to make breaking changes to CUDA I don't know about that. You could kinda argue the opposite. "We improved CUDA. Oh it stopped working for you on AMD hardware? Too bad. Buy Nvidia next time"
- outside415 3y agoNVIDIA is about ecosystem plays, they have no interest in sabotage or anti competition plays. Leave that to apple and google and their dumb app stores and mobile OSs.
- 0x457 3y ago> NVIDIA is about ecosystem plays, they have no interest in sabotage or anti competition plays. Are we talking about the same NVIDIA? The entire Nvidia GPU strategy for nvidia is - make a feature (or find existing one) that performs better on their cards - pay developers to use (and sometimes misuse) it extensively.
- mnau 3y agoAlso known as OS/2: Redux strategy.
- freeone3000 3y agoMost CUDA applications do not target the newest CUDA version! Despite 12.1 being out, lots of code still targets 7 or 8 to support old NVIDIA cards. Similar support for AMD isn’t unthinkable (but a rewrite to rocm would be).
- notso411 3y ago[dead]
- 2OEH8eoCRo0 3y agoQuestion: Why aren't we using LLMs to translate programs to use ROCm? Isn't translation one of the strengths of LLMs?
- JonChesterfield 3y agoYou can translate cuda to hip using a regex. LLM is rather overkill.
- mogoh 3y agoWhy is CUDA so prevalent oppose to its alternatives?
- smoldesu 3y agoAt first, it was because Nvidia had a wide variety of highly used cards that almost all support some form of CUDA. By-and-large, your gaming GPU could debug and run the same code that you'd scale up to a datacenter, which was a huge boon for researchers and niche industry applications. With that momentum, CUDA got incorporated into a lot of high-performance computing applications. Few alternatives show up because there aren't many acceleration frameworks that are as large or complete as CUDA. Nvidia pushed forward by scaling down to robotics and edge-compute scale hardware, and now are scaling up with their DGX/Grace platforms. Today, Nvidia is prevalent because all attempts to subvert them have failed. Khronos Group tried to get the industry to rally around OpenCL as a widely-supported alternative, but too many stakeholders abandoned it before the initial crypto/AI booms kicked off the demand for GPGPU compute.
- JonChesterfield 3y agoOpencl was the alternative, came along later, couldn't write a lot of programs that cuda can. Cuda is legitimately better than opencl.
- enonimal 3y agoFrom the ARCHITECTURE.md: > Those pointers point to undocumented functions forming CUDA Dark API. It's impossible to tell how many of them exist, but debugging experience suggests there are tens of function pointers across tens of tables. A typical application will use one or two most common. Due to they undocumented nature they are exclusively used by Runtime API and NVIDIA libraries (and in by CUDA applications in turn). We don't have names of those functions nor names or types of the arguments. This makes implementing them time-consuming. Dark API functions are are reverse-engineered and implemented by ZLUDA on case-by-case basis once we observe an application making use of it.
- leeoniya 3y agofertile soil for Alyssa and Asahi Lina :) https://rosenzweig.io/ https://rosenzweig.io/ https://vt.social/@lina https://vt.social/@lina
- deleted 3y ago[deleted]
- Cu3PO42 3y agoI'm really rooting for AMD to break the CUDA monopoly. To this end, I genuinely don't know whether a translation layer is a good thing or not. On the upside it makes the hardware much more viable instantly and will boost adoption, on the downside you run the risk that devs will never support ROCm, because you can just use the translation layer. I think this is essentially the same situation as Proton+DXVK for Linux gaming. I think that that is a net positive for Linux, but I'm less sure about this. Getting good performance out of GPU compute requires much more tuning to the concrete architecture, which I'm afraid devs just won't do for AMD GPUs through this layer, always leaving them behind their Nvidia counterparts. However, AMD desperately needs to do something. Story time: On the weekend I wanted to play around with Stable Diffusion. Why pay for cloud compute, when I have a powerful GPU at home, I thought. Said GPU is a 7900 XTX, i.e. the most powerful consumer card from AMD at this time. Only very few AMD GPUs are supported by ROCm at this time, but mine is, thankfully. So, how hard could it possibly to get Stable Diffusion running on my GPU? Hard. I don't think my problems were actually caused by AMD: I had ROCm installed and my card recognized by rocminfo in a matter of minutes. But the whole ML world is so focused on Nvidia that it took me ages to get a working installation of pytorch and friends. The InvokeAI installer, for example, asks if you want to use CUDA or ROCm, but then always installs the CUDA variant whatever you answer. Ultimately, I did get a model to load, but the software crashed my graphical session before generating a single image. The whole experience left me frustrated and wanting to buy an Nvidia GPU again...
- Certhas 3y agoThey are focusing on HPC first. Which seems reasonable if your software stack is lacking. Look for sophisticated customers that can help build an ecosystem. As I mentioned elsewhere, 25% of GPU compute on the Top 500 Supercomputer list is AMD. This all on the back of a card that came out only three years ago. We are very rapidly moving towards a situation where there are many, many high-performance developers that will target ROCm.
- ametrau 3y agoIs a top 500 super computer list a good way of measuring relevancy in the future?
- CapsAdmin 3y agoHope this can benefit from the seemingly infinite enthusiasm from rust programmers
- sharts 3y agoAMD fail to realize software toolchain is what makes nvidia great. AMD thinks the hardware is all that’s needed
- JonChesterfield 3y agoNvidia's toolchain is really not great. Applications are just written to step around the bugs. ROCm has different bugs, which the application workarounds tend to miss.
- bornfreddy 3y agoYes. This is what makes Nvidia's toolchain, if not great, at least ok. As a developer I can actually use their GPUs. And what I developed locally I can yhen run on Nvidia hardware in the cloud and pay by usage. AMD doesn't seem to understand that affordable entry-level hardware with good software support is key.
- JonChesterfield 3y agoAh yes, so that one does seem to be a stumbling block. ROCm is not remotely convinced that running on gaming cards is a particularly useful thing. HN is really sure that being able to develop code on ~free cards that you've got lying around anyway is an important gateway to running on amdgpu. The sad thing is people can absolutely run ROCm on gaming cards if they build from source. Weirdly GPU programmers seem determined to use proprietary binaries to run "supported" hardware, and thus stick with CUDA. I don't understand why AMD won't write the names of some graphics cards under "supported", even if they didn't test them as carefully as the MI series, and I don't understand why developers are so opposed to compiling their toolchains from source. For one thing it means you can't debug the toolchain effectively when it falls over, weird limitation to inflict on oneself. Strange world.
- sorenjan 3y agoMaybe someone that's trying to use a GPU to solve a particular problem doesn't necessarily also have the time, energy, knowledge, or interest to also first 1) find out how to construct the toolchain, 2) build said toolchain, and 3) debug the toolchain. Just because you're a programmer writing code for physics simulations, image processing, AI models, or whatever, doesn't mean you also want to spend hours or days on getting your tools working before you can even start writing your own code. And then do it again when deploying on another computer. And it's really not surprising that people, GPU programmers included, doesn't want to spend time and money on trying out unsupported hardware and software combinations when again, it's supposed to be a tool to get a job done. If I got some Phillips head screws I'm not reaching for a flat head screwdriwer even though it probably will work, and if it's the only thing I have I'll buy some Phillips head ones for the next project.
- CapsAdmin 3y agoOne thing I didn't see mentioned anywhere apart from the repos readme: > PyTorch received very little testing. ZLUDA's coverage of cuDNN APIs is very minimal (just enough to run ResNet-50) and realistically you won't get much running.
- yieldcrv 3y agoSam could get more chips for way less than $7 trillion if he helps fund and mature this
- JonChesterfield 3y agoI'm pretty tired of the business model of raising capital from VCs to give to Nvidia.
- Keyframe 3y agoThis event of release is however a result of AMD stopped funding it per "After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs. One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today." from https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq so, same mistake intel made before.
- VoxPelli 3y agoSounds like he had a good contract, would be great to read more about that, hopefully more devs could include the same phrasing!
- nikanj 3y agoThis should be the top comment here, people are getting their hopes up for nothing
- CuriousCosmic 3y agoI mean it could also be that there was no business case for it as long as it remained closed source work. If the now very clearly well functioning implementation continues to perform as well as it is, the community may be able to keep it funded and functioning. And the other side of this is that with renewed AMD interest/support for the rocm/HIP project, it might be just good enough as a stopgap step to push projects towards rocm/HIP adoption. (included below is another blurb from the readme). > I am a developer writing CUDA code, does this project help me port my code to ROCm/HIP? > Currently no, this project is strictly for end users. However this project could be used for a much more gradual porting from CUDA to HIP than anything else. You could start with an unmodified application running on ZLUDA, then have ZLUDA expose the underlying HIP objects (streams, modules, etc.), allowing to rewrite GPU kernels one at a time. Or you could have a mixed CUDA-HIP application where only the most performance sensitive GPU kernels are written in the native AMD language.
- pk-protect-ai 3y ago> After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs Who was responsible at AMD for this project and why is he still not fired???????? How brain dead someone have to be to reject the major market share??????
- shmerl 3y agoAnything that breaks CUDA lock-in is great! This reminds how DX/D3D lock-in was broken by dxvk and vkd3d-proton. > It apparently came down to an AMD business decision to discontinue the effort Bad decision if that's the case. May be someone can pick it up, since it's open now.
- swozey 3y agoI may have missed it in the article, but this post would mean absolutely nothing to me except for the fact that last week I got into stable diffusion so I'm crushing my 4090 with pytorch and deepspeed, etc and dealing with a lot of nvidia ctk/sdk stuff. Well, I'm actually trying to do this in windows w/ wsl2 and deepmind/torch/etc in containers and it's completely broken so not crushing currently. I guess awhile ago it was found that Nvidia was bypassing the kernels GPL license driver check and I read that kernel 6.6 was going to lock that driver out if they didn't fix it, and from what I've read there was no reply or anything done by nvidia yet. Which I think I probably just can't find. Am I wrong about that part? We're on kernel 6.7.4 now and I'm still using the same drivers. Did it get pushed back, did nvidia fix it? Also, while trying to find answers myself I came across this 21 year old post which is pretty funny and very apt for the topic https://linux-kernel.vger.kernel.narkive.com/eVHsVP1e/why-is-nvidia-given-gpl-d-code-to-use-in-closed-source-drivers https://linux-kernel.vger.kernel.narkive.com/eVHsVP1e/why-is... I'm seeing conflicting info all over the place so I'm not really sure what the status of this GPL nvidia driver block thing is.
- bongodongobob 3y agoJust run that stuff in Linux, you're making it harder than it needs to be. Can it work in Windows? Sure. Is there as much documentation? Not even close.
- zoobab 3y ago"For reasons unknown to me, AMD decided this year to discontinue funding the effort and not release it as any software product." Managers at AMD never heard of AI?
- ultra_nick 3y agoIf anyone wants to work in this area, AMD currently has a lot of related job posts open.
- navbaker 3y agoThe other big need is for a straightforward library for dynamic allocation/sharing of GPUs. Bitfusion was a huge pain in the ass, but at least it was something. Now it’s been discontinued, the last version doesn’t support any recent versions of PyTorch, and there’s only two(?) possible replacements in varying levels of readiness (Juice and RunAI). We’re experimenting now with replacing our Bitfusion installs with a combination of Jupyter Enterprise Gateway and either MIGed GPUs or finding a way to get JEG to talk to a RunAI installation to allow quick allocation and deallocation of portions of GPUs for our researchers.
- irusensei 3y agoI'll try later with projects in which I had issues to make it work like TortoiseTTS. I'm not expecting comparable Nvidia speeds but definitely faster than pure CPU.
- Farfignoggen 3y agoPhoronix Article from earlier(1): "While AMD ships pre-built ROCm/HIP stacks for the major enterprise Linux distributions, if you are using not one of them or just want to be adventurous and compile your own stack for building HIP programs for running on AMD GPUs, one of the AMD Linux developers has written a how-to guide. "(1) (1) "Building An AMD HIP Stack From Upstream Open-Source Code Written by Michael Larabel in Radeon on 9 February 2024 at 06:45 AM EST." https://www.phoronix.com/news/Building-Upstream-HIP-Stack https://www.phoronix.com/news/Building-Upstream-HIP-Stack
- JonChesterfield 3y agoHähnle is one of our best, that'll be solid. http://nhaehnle.blogspot.com/2024/02/building-hip-environment-from-scratch.html http://nhaehnle.blogspot.com/2024/02/building-hip-environmen.... Looks pretty similar to how I build it. Side point, there's a driver in your linux kernel already that'll probably work. The driver that ships with rocm is a newer version of the same and might be worth building via dkms. Very strange that the rocm github doesn't have build scripts but whatever, I've been trying to get people to publish those for almost five years now and it just doesn't seem to be feasible.
- Farfignoggen 3y agoFrom the Phoronix comments section of the Article that I linked to: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1442101-building-an-amd-hip-stack-from-upstream-open-source-code#post1442342 https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... And I'm on Linux Mint 21.3 and so how to change any instillation script to think that Mint is Ubuntu to get that to maybe work there but there's no how-to for Mint like the one that AMD provides for Ubuntu! And really that's compiled By AMD for the specific Linux Kernel so not any DKMS sort of methods there AFAIK! but I'm no Linux Expert and just want some one-click install or that to ship with the Distro already working so Blender 3D's iGPU/dGPU accelerated Cycles rendering is possible on AMD Radeon consumer GPUs.
- JonChesterfield 3y ago
- fancyfredbot 3y agoWouldn't it be fun to make this work on intel graphics as well.
- codedokode 3y agoAs I understand, Vulkan allows to run custom code on GPU, including the code to multiply matrices. Can one simply use Vulkan and ignore CUDA, PyTorch and ROCm?
- Const-me 3y agoI did a few times with Direct3D 11 compute shaders. Here’s an open-source example: https://github.com/Const-me/Cgml https://github.com/Const-me/Cgml Pretty sure Vulkan gonna work equally well, at the very least there’s an open source DXVK project which implements D3D11 on top of Vulkan.
- eddiewithzato 3y agoof course, but then you are just recreating CUDA. And that won’t scale well across an industry since each company would have their own language. AMD can just do what you are describing and then sell it as a standard. I mean they literally did that, but then dropped it so yea
- sorenjan 3y agoncnn uses Vulkan for GPU acceleration, I've seen it used in a few projects to get AMD hardware support. https://github.com/Tencent/ncnn https://github.com/Tencent/ncnn
- 0xDEADFED5 3y agothere's a pretty cool Vulkan LLM engine here for example: https://github.com/mlc-ai/mlc-llm https://github.com/mlc-ai/mlc-llm
- PeterisP 3y agoYou probably can, but why would you? The main (only?) reason to ignore the CUDA-based stack is so that you could save a bit of money by using some other hardware instead of nVidia. So the amount of engineering labor/costs you should be willing to accept is directly tied to how much hardware you intend to buy or rent and what % discount, if any, the alternative hardware enables compared to nVidia. So if you'd want to ignore CUDA+PyTorch and reimplement all of what you need on top of Vulkan.... well, that becomes worthy of discussion only if you expect to spend a lot on hardware, if you really consider that savings on hardware can recoup many engineer-years of costs - otherwise it's more effective to just go with the flow.
- Bobbyben 3y ago[flagged]
- TheMagicHorsey 3y agoI'm hoping something like Mojo makes it so the CUDA lock-in fades over time. Its never a good thing to have one company, like Nvidia, have a stranglehold on the hardware the whole ecosystem evolves on.
- throwaway2037 3y agoFrom the same repo, I found this excellent, well-written architecture document: https://github.com/vosen/ZLUDA/blob/master/ARCHITECTURE.md https://github.com/vosen/ZLUDA/blob/master/ARCHITECTURE.md I love the direct, "no bullshit" style of writing. Some gems: > Anyone familiar with C++ will instantly understand that compiling it is a complicated affair. > Additionally CUDA allows, to a large degree, mixing CPU code and GPU code. What does all this complexity mean for ZLUDA? Absolutely nothing > Since an application can dynamically link to either Driver API or Runtime API, it would seem that ZLUDA needs to provide both. In reality very few applications dynamically link to Runtime API. For the vast majority of applications it's sufficient to provide Driver API for dynamic (runtime) linking.
- Donaldbendo 3y ago[flagged]