OneAPI support?

[oscarbg]

Hi,
if we could get an Orochi OneAPI backend, then GPU desktop support, should be complete, from a vendor viewpoint..
hope it gets added eventually.. and I get notified when it's done by having opened the issue :-)
EDIT: don't know if OneAPI is currently as complete as HIP and CUDA like the rtc component for example so adding support for it, is possible or easy..

[takahiroharada]

Orochi is designed to add more backends if needed. Adding intel support makes sense to complete the project. We are happy to work with anyone who's interested in adding it although we don't have any plan to add it at the moment.

[mudapanda2]

I'm going to be attempting to tackle this or a portion thereof for a passion project I've started to take all the Cycles rendering backends and port them to Orochi while attempting to use Orochi to implement more. CUDA/Optix, RoCM/Vulkan RT, resurrecting OpenCL as an option with RT (Maybe). Right now the most difficult part is deciding how/why/who/what where when there's big projects and sweeping changes ongoing in this arena, Makes a guy want to turn into a syclpath.

Passion project goal is to reduce Cycles renderer code from 4 implementations to 1 and then ask Orochi to conduct the symphony to make that 1 work on whatever hardware is presented. So more of a 1 headed, 8 tailed dragon.

[takahiroharada]

Actually, I started one api level zero hook up to Orochi while ago (which I haven't had time to go back and finish up), which was working fine although there are some stuff which didn't go as clean as I want as the model is slightly different.

[oscarbg]

@takahiroharada nice! Can publish even the “unfinished work” as a branch on public orochi github repo? so someone can start from there and iterate on your work..
Think would be nice so your work isn’t lost..

[takahiroharada]

@oscarbg FYI, it's in our fork right now but I can push the branch to this orochi repo.

https://github.com/amdadvtech/Orochi/tree/feature/ORO-0-oneapi
amdadvtech@3eaabdc

Not all tests are working but basic and important ones are working

Note: Google Test filter = *kernelExec*:*init*:*deviceprops*:*malloc*
[==========] Running 6 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 6 tests from OroTestBase
[ RUN      ] OroTestBase.init
[       OK ] OroTestBase.init (91 ms)
[ RUN      ] OroTestBase.deviceprops
executing on Intel(R) Arc(TM) A770 Graphics ()
512 multiProcessors
[       OK ] OroTestBase.deviceprops (6 ms)
[ RUN      ] OroTestBase.malloc
[       OK ] OroTestBase.malloc (28 ms)
[ RUN      ] OroTestBase.kernelExec
[       OK ] OroTestBase.kernelExec (81 ms)
[ RUN      ] OroTestBase.kernelExecPreCompiled
0: 123
1: 123
2: 123
3: 123
4: 123
5: 123
6: 123
7: 123
8: 123
9: 123
10: 123
11: 123
12: 123
13: 123
14: 123
15: 123
16: 123
17: 123
18: 123
19: 123
20: 123
21: 123
22: 123
23: 123
24: 123
25: 123
26: 123
27: 123
28: 123
29: 123
30: 123
31: 123
32: 123
33: 123
34: 123
35: 123
36: 123
37: 123
38: 123
39: 123
40: 123
41: 123
42: 123
43: 123
44: 123
45: 123
46: 123
47: 123
48: 123
49: 123
50: 123
51: 123
52: 123
53: 123
54: 123
55: 123
56: 123
57: 123
58: 123
59: 123
60: 123
61: 123
62: 123
63: 123
[       OK ] OroTestBase.kernelExecPreCompiled (126 ms)
[ RUN      ] OroTestBase.kernelExecPreCompiled1
executing on Intel(R) Arc(TM) A770 Graphics ()
512 multiProcessors
[       OK ] OroTestBase.kernelExecPreCompiled1 (93 ms)
[----------] 6 tests from OroTestBase (427 ms total)

[----------] Global test environment tear-down
[==========] 6 tests from 1 test case ran. (428 ms total)
[  PASSED  ] 6 tests.

[oscarbg]

Nice! Will take a look.. thanks..

[takahiroharada]

The change was copied to a branch in this repo.

https://github.com/GPUOpen-LibrariesAndSDKs/Orochi/tree/feature/ORO-0-oneapi

[nat42]

Stuff like this really exemplifies the issue I have with AMD's attitude with GPUOpen, it feels much more about being opensource as a bullet point than making the tools developers would want to be API agnostic and support all major GPU vendors.

AMD wants to compete with Nvidia and unlock some of the marketshare, but developers if they care, just want to not be locked in and have code that works everywhere. That this project doesn't see a reason to make OneAPI (or CPU) backends work as a priority (or bring them up to the 2.0 code) dooms this to being for those devs that care to support AMD specifically. It seems just as self serving as Nvidia's vendor lock in, except that they have the dominant position and AMD is playing catchup.