Vulkan 1.3 implementation for AmigaOS 4

@kas1e

NVIDIA is not so closed sourced as it used to be.

@kas1e
AFAIK Vulkan is meant to be a lower level API than OpenGL so I think it only makes sense to build the graphics stack on top of Vulkan talking to its own driver, otherwise it won't have the less CPU usage or any other advantage. However in that case you also need to make a P96 driver so graphics.library can use it otherwise you'd have two drivers trying to access the same card.

@kas1e @balaton

One day...

https://docs.mesa3d.org/vulkan/index.html

https://en.wikipedia.org/wiki/Graphics_Core_Next

@balaton

RadeonHD_RM.resource is the direct hardware API to 3D stuff.
not sure how documented it is..

this what Warp3DNova uses.

https://www.youtube.com/watch?v=oDpgNZESHgI

@kas1e

I don't think it's slow, but it can certainly be optimized further. This tech demo shows that it already works really well.

Created with the new VulkanOs4 SDK.

EFFECTS
-------
- Two rotating 3D tori with orbiting camera
- AmigaOS4 logo texture mapped on torus surface
- Rainbow color gradient with Phong lighting
- Chromatic aberration effect
- Pulsing rim light with rainbow colors
- Lightning bolts on torus surface
- Lens flare effect
- Rainbow tunnel background
- Sine-wave text scroller at bottom

Coming soon to Os4depot

@Majestro
Quote:

Nice :) Hope that when Derfs will make it working directly, the same binary builds with current SDK will simple work just faster. But still tasty :)

@Maijestro

Hi Everyone.

Installed this on my AmigaOne 500 with Radeon RX 550 all the latest drivers from A-EON, latest Uboot, and latest AmigaOS 4.1.

This Vulkan implementation is great. The Demos work great and the Donut demo (thanks Maijestro) is awesome. I did have it locks up once but other than that, it is great. Great work everyone. Looking forward to games using this.

Yogi

@yogi32

There is debug output turned on for this release, so if anyone has a crash/freeze and you can get serial output or use DumpDebugBuffer please add it here or on github so I can look into it. Thanks for using VulkanOS4!

@kas1e

That looks really strange. Is your x1000 fully functional?
My x86_64 machine is from 2012—does it perform better than the x1000?
I'm using a low-end Radeon HD -> https://www.techpowerup.com/gpu-specs/asus-hd-7750.b614
I tested this on QEMU GPU passthrough 11-rc1

SAM440 HD7750 - Cow3D - 45 fps

@LiveForIt, @derfs

Quote:
It's an internal API. You'd have to ask A-EON for access to it.

An interim option would be to ditch gles2 as a go-between and run Vulkan through Warp3D Nova directly. Warp3D Nova's design is influenced by the draft Vulkan spec that was available back then (it was still a work-in-progress back then). So, the APIs are a closer match than Vulkan to OpenGL.

I'm pleasantly surprised that you got it working, because I thought Vulkan's design and the GPUs being of opposite endienness to the CPU would be a massive headache. I remember looking at it early on, and it looked like you were writing directly into GPU buffers, without enough info about how the data is structured (needed for endianness conversion). Warp3D Nova's API has functions to specify the data layout specifically to handle this.

Hans

@HansQuote:
Thanks Hans. The endianness is handled by byte-swap at SPIR-V load time, and SPIRV-Cross outputs GLSL text for the GPU path, so W3DN/OGLES2 takes it from there.

Yes, Vulkan -> W3DN directly would be a cleaner path than going through OGLES2. The APIs do map well. For now the ogles2_vk ICD works and gives us GPU acceleration today, which was the goal.

This is only possible due to your work - Thanks!

@smarkusg

Quote: "@kas1e 23 (cow3d) - 28 FPS That looks really strange. Is your x1000 fully functional?"

I have here in X1000 same low FPS with RX550.
Also in the vulkandonut demo very low. Strange.

@TearsOfMe
I thought @kas1e was just having hardware issues.
I didn't show the rest of the tests because they were even stranger...


I gave an example of the version I'm using, “QEMU GPU passthrough 11-rc1,” but it doesn't really matter because it works the same way on QEMU 9 and 10.
In QEMU, there’s even a slowdown in GPU passthrough performance under PPC.
The QEMU developers don’t have time to look into it and debug it.
Of course, I don’t blame them—they have other, more important things to do.

As for the X1000, this system was considered the best-optimized Amiga NG.
Maybe some Vulkan optimization, maybe some other issue.

Can you run the same test I provided and post the results?
Maybe it will help someone figure out why it’s acting up for you and @kas1e.

Thanks!

@kas1e

Yes thats correct - As the vulkan 1.3 API is complete it will get quicker as parts of VulkanOS4 are updated.

If you get poor FPS on Cow3D then send me the debug log after running it for a few seconds so I can take a look.

@derfs

[quote]Thanks Hans. The endianness is handled by byte-swap at SPIR-V load time, and SPIRV-Cross outputs GLSL text for the GPU path, so W3DN/OGLES2 takes it from there.[/quot]
bte-swapping the SPIR-V code s piss easy. Handling the vertex, and data bufers is where things get compicated.

everythig is fine so long as you use 32-bit data everywhere. Then you just 32-bit byte-swap all the buffers as you transfer to/from the GPU. Truble starts once a developer packs other data types in, to minimise bandwidth use and push the performance. For example, using vertex data with 8/16-bit data types, plus 32-bit ones. at that point, the APi needs some kind of data descriptor that maps out the datatypes. Otherwise, the drivers simply don't have the ino needed to do the conversion properly.

When I looked at the draft Vulkan spec, there weren't any descriptors giving the ino needed (unless I missed something).

hans

@smarkusg

I did this remark in the SDL3 thread where I was surprised about the performance on my machine.

Maybe it is something that can be optimized on our system.

Kind regards,

@Hans

Ah ok - it looks like the following was added after you looked at the Vulkan spec.

VkVertexInputAttributeDescription in the pipeline's vertex input state gives:
- format (e.g. VK_FORMAT_R8G8B8A8_UNORM, VK_FORMAT_R16G16_SFLOAT, VK_FORMAT_R32G32B32_SFLOAT)
- offset within the vertex buffer
- binding number

Currently W3DN handles the GPU-side endianness. The data never needs CPU-side byte-swapping because it flows through the existing driver stack which already handles this.

@Petrol

You can try Ragemem or Gfxbench2D which have VRAM read test.

@derfs

Serial logging also explains the cow performance I think.

30 FPS on Radeon RX by default.
200 FPS with sashimi redirected to a file.