Vulkan 1.3 implementation for AmigaOS 4

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 (3)

derfs

Re: Vulkan 1.3 implementation for AmigaOS 4

Posted on: Yesterday 19:16 #41

Not too shy to talk

@Capehill

True, however it *should* impact all platforms equally but X1000 seems to be hit especially hard so what do I know

smarkusg

Re: Vulkan 1.3 implementation for AmigaOS 4

Posted on: Yesterday 19:44 #42

Quite a regular

@Capehill
I ran another test.
My standard benchmark result is 91 FPS.
With Sashimi enabled in “shell” mode (outputting to the console), I get 23 FPS.
With Sashimi enabled in “quiet” mode (no console output), I get 70 FPS.

Just running Sashimi to capture that large debug serial stream on my slow hardware eats up 20 FPS

Hans

Re: Vulkan 1.3 implementation for AmigaOS 4

Posted on: Today 2:26 #43

Home away from home

@derfs

Quote:

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

That might have been in the draft too.

What about other data buffers, such as shader constants? IIRC, you could bulk upload data to the GPU, and then let the shaders read from anywhere within the buffer. In this situation, you only know the data layout when it's actually being used by a shader.

Being able to share pointers and data directly between CPU & GPU is really nice, from an API perspective, because it simplifies things (handling the different address spaces was a driver nightmare). From memory, Apple's Metal API has this thanks to a unified memory architecture where both the CPU and GPU use the same address space. Unfortunately, this is only possible if the CPU and GPU use the same endianness, and have MMUs set up to match each other. So the hardware needs to be designed for it.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

Hans

Re: Vulkan 1.3 implementation for AmigaOS 4

Posted on: Today 2:37 #44

Home away from home

@smarkusg

Quote:

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

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!

Does your x86 qemu system configure the RadeonRX card to use PCIe v3 by any chance? That would give you a big bandwidth advantage over the A1-X1000, and its PCIe v1 slot.

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

derfs

Re: Vulkan 1.3 implementation for AmigaOS 4

Posted on: Today 8:00 #45

Not too shy to talk

@Hans

This is all WIP still, and its not like I have not used suggestions from Claude-AI, but this is how it currently works.

For push constants, the transpiler knows the struct layout from the SPIR-V reflection data, so it can emit correctly-typed uniforms on the GLSL side. The data goes through the GL uniform API, so the driver stack handles any byte-swapping the same way it would for any other GL program, so nothing special is needed on our end.

For UBOs the descriptor infrastructure's there, but right now everything gets flattened to push constants during transpilation. Partly because GLES2 doesn't have native UBOs, and partly because 128 bytes has been enough so far. Once shaders start reading from arbitrary offsets in a bulk buffer, the driver needs to know what type lives at each offset to get the byte order right. The plus side is that the information is all in the SPIR-V, so it's solvable without applications having to do anything extra.

The project is far from finished but its a start!

Register To Post	« 1 2 (3)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )