After fixing problem with negative error codes in libdrm (fix is incomplete, I currently have no idea how to better fix error codes sign incompatibility), vulkan_radeon driver is actually loaded and probed DRM devices (and not found anything).
15 Likes
hardware from 2012 on iirc support vulkan, AMD, were talking 8yr old cards here.
there is no way the haiku devs whether inside or outside of the official channels can support such a broad swath of hardware.
GPUs are complex as are graphics apus etc
vulkan has opengl wrappers, if older hardware isn’t supported, this is just how it is
On my intel HD 4000 gpu which is a fairly old 2012 gpu, intel put vulkan support on linux, it is not very performing gpu but there is. On other older intel GPU i don’t know if there is vulkan, i also have an AMD Radeon HD 7600 on the same laptopo and in that case Vulkan is not supported, although it is a well-performing OpenGL/DirectX gpu, it is not supported mainly because they are a generation of gpu that AMD has abandoned the development of drivers, even on Linux no one has developed the vulkan support only a well good OpenGL ( Which has improved over the years leading to OpenGL 4.6 support while on windows there is no such support on these gpus) but being a generation of GPU that had Mantle (essentially Vulkan before amd released it as an opensource standard) could be gpu that could happily support vulkan.
So I think even older gpus could “easily” benefit from having vulkan supported.
This number of fps is indicating that it is accelerated by the gpu, or is it just via cpu, which then in the case of the intel gpu, which are embedded in the cpu, it could be the same thing or am I wrong?
What generation of GPU/CPU are you testing on?
From what I know from other channels, modern CPUs with many cores, (32, 64 or more cores), perform well with vulkan, to the point of competing with mid-range gpus
For interesting information this is the blog of the developer who has advanced the support of the old generation radeon hd from HD 2000 to HD 8000 on linux, he is a good guy, it often happened to me that he explained some concepts to me or was available when I posted bug reports on my radeon. he is also one of the developers of Lavapipe.
This is the blog of the genius who developed zink, he is another good boy who replies to the comments on his blog
this is the developer blog for the Broadcom VideoCore VI raspberry pi 4 gpu, the V3DV driver, it also has the comments available
https://blogs.igalia.com/itoral/
I hope this informations are useful, perhaps, for you experienced HAIKU developers, if you have any questions, they can give you some help or advice thanks to their experience.
the hd7600 is over 8 yrs old iirc, it’s sucks, but, what can you do ? haiku doesn’t have the man power.
now if 3d accell attracts devs, then, well, there’s opportunity to fix older cards.
my personal take is, gaming is expensive, so, suck it up chuck
Well I wouldn’t say it sucks, obviously it’s not competitive with the new generation gpu but trust me it’s still a nice gpu.
This is an old video from 2018 or 2019, which I used to report some bugs to the blender developers.
As you can see, EEVEE realtime rendering, is obviously not performing in realtime, but it allows a complete rendering in OpenGL, moreover, by deactivating the advanced shading it has excellent performances that allow modeling or other in blender, even with meshes with a consistent polygonal density.
I know for direct information, that these gpus on linux have the same R600 Gallium driver, covering 10 years of gpu, from 2006 radeon HD 2000 to 2016 radeon HD 8000 if I’m not mistaken, so anyway with one driver you cover a lot of gpu .
Games of the caliber of The Whitcher were running on this gpu, which is no small feat.
Anyway we were talking about the potential support of old GPUs that only have OpenGL, I just pointed out, that by supporting Mantle, Vulkan could potentially approach these GPUs as well.
1 Like
Mantle is just an early version of Vulkan. It was donated to the Khronus Group without the Mantle trademark. Hence the name change.
1 Like
mantle/vulcan are the same thing, the radeon atombios system should work since the big architecture changes were all late 2012 wh hd5xxx cards iirc.
but again, the shortest cleanest most simple route, is vulkan, at least we get 3d rendering,
Vulkan is also nice that it use add-on architecture. For example windowing system integration (WSI, API for rendering to a window) can be provided in separate add-on making drivers windowing system independent. I managed to compile and load WSI add-on from here: Mesa / vulkan-wsi-layer · GitLab. But no rendering to BWindow/BView is implemented yet.
3 Likes
I managed to run gears Vulkan demo with headless WSI and output to file. Note that FPS is low because of uncompressed PPM file output for each frame.
16 Likes
how difficult is the path to on screen rendering from this point ?
Not really difficult. Haiku BView output should be added here: wsi · master · Mesa / vulkan-wsi-layer · GitLab.
2 Likes
so I’m understanding where this is at.
vulkan api to gpu IR to memory manager to on screen render ?
or is this all just the software renderer ?
This is software lavapipe renderer. Hardware GPU renderer need kernel driver part from Linux kernel sources that is not ported yet, here is WIP port attempt by andreasdr.
When GPU rendering will be available, GPU memory can be copied to BBitmap in RAM and displayed in usual Haiku way. This can be done as initial step before DRM modesetting and compositor will be implemented.
4 Likes
I’d be very curious if the linux driver is worth porting as a whole unit. ???
does valve publish there driver or are the using public or private drivers ???
either way, great progress, certainly laying the ground work.
years ago before my life went crazy, i was learning about the 3d hardware , c++ etc.
I’d say working on using the GPU 2d accelerated drawing functions would be a good start, basically everything i was reading was saying to push everything to the video output buffer ram,
so push drawing data, shaders etc to sys ram, gpu picks up from allocated block area, from that point forward, no data outside od latebcy frame info should move back to sts/cpu ram.
basically open ended, i remember linux had some junk for headless rensering where it complicated the ring bus heavily for these unneeded use cases for desktop.
atombios is involved in this process for 2d and 3d drivers to setup clocks, allocate memory etc
More complex demos are also working:
23 Likes
if you haven’t, you may want to look at the docs here, if you’re thinking about hardware acceleration next
It still need Linux kernel AMDGPU driver.
1 Like
libdrm_amdgpu, i have not looked through all of this as of yet, so you might be way ahead of me here.
this driver is mostly os agnostic
Only its userland part if I am correct. Kernel part is Linux-specific.