AMD GPUOpen Working On A New "gpurt" Open-Source Project

[phoronix]

Phoronix: AMD GPUOpen Working On A New "gpurt" Open-Source Project

AMD's GPUOpen team quietly setup a new GitHub repository for "gpurt", presumably a new ray-tracing related software effort...

https://www.phoronix.com/scan.php?page=news_item&px=AMD-GPUOpen-gpurt

[CochainComplex]

Interesting

[Mahboi]

Can I hope for an "OpenEncoding" someday?

I mean I try with VAAPI, but the thing simply has problems. A refresher/new code may really be good...

[Barley9432]

The amount of duplicated effort AMD has in the Linux space is ridiculous. They should just do what Intel does, support one driver stack and that's it. RADV would be further along if they weren't given peanuts to work with.

[tildearrow]

Could also be GPU Run-Time or GPU Real-Time?

[Guest]

The amount of duplicated effort AMD has in the Linux space is ridiculous. They should just do what Intel does, support one driver stack and that's it. RADV would be further along if they weren't given peanuts to work with.

Don't even get me started about how there's 3 different OpenCL drivers all with wildly varying levels of support. Could make it easy by just pouring efforts into Clover (they did it with amdgpu), but somehow it's more reasonable to make CUDA even more appealing with its simplicity.

[AndyChow]

Can I hope for an "OpenEncoding" someday?

I mean I try with VAAPI, but the thing simply has problems. A refresher/new code may really be good...

Last time I tried support for accelerated encoding worked with amdgpu, at least when using ffmpeg. Couldn't get it to work with OBS, which I'm guessing you're using.

Edit: I guess it depends on your card too. Fiji and Tonga had problems that will never get fixed. My card was a Polaris.

[bridgman]

Don't even get me started about how there's 3 different OpenCL drivers all with wildly varying levels of support. Could make it easy by just pouring efforts into Clover (they did it with amdgpu), but somehow it's more reasonable to make CUDA even more appealing with its simplicity.

Not sure about "3" unless you are talking about the different generations of back ends ? What are the three you are thinking about ?

As far as I know we have always had one OpenCL implementation, although the device back-end has changed over time. We did spend a few years also contributing to Clover in the hope of seeing it established as a cross-vendor standard, but by ~2014 we were still the only significant contributor and so decided to run our primary OpenCL compiler/runtime over the open source drivers instead and open-sourced it as part of the ROCm stack.

As far as I know we only have one OpenCL implementation today, running over PAL on Windows and ROCR on Linux for Vega and newer. For older parts (before Vega) we are running over the older Orca back end, using code from the old OpenGL driver.

[Quackdoc]

I'll take "no support for polaris and before" jim

[stalkerg]

bridgman I believe two people and one year are enough to bring Clover into working shape for most Desktop tasks. (LibreOffice, GIMP/GEGL, Darktable...) even for r600 cards. After, that maybe Intel or mobile developers will join.
The main criticism about AMD now is that we have no consumer-level solution for computations.
PS I basically understand why we have an alternative to RADV, you many times mention it but the fact is still here - AMDVLK, ROCm, closed AMDGPU drivers, not for 99% of people on this site.