Hadn’t realized they split it like so, wonder how much code can be recycled though ???
1 Like
I managed to run RadeonGfx on the same screen as used by app_server. radeon_hd modesetting unfortunately don’t work (#17461), so I use mode set by UEFI GOP. I also made memory controller VRAM segment start address preserved and framebuffer memory preallocated to not cause conflict with mode set by UEFI GOP. If not doing so, screen will turn white.
29 Likes
I see GPU page faults when moving any window:
InterruptPacket(146, 2256908, 0, 0)
VM_CONTEXT1_PROTECTION_FAULT_ADDR: 0
VM_CONTEXT1_PROTECTION_FAULT_STATUS: (prot: {}, clientId: 0, vmId: 0)
InterruptPacket(146, 10645516, 0, 0)
VM_CONTEXT1_PROTECTION_FAULT_ADDR: 0x5000
VM_CONTEXT1_PROTECTION_FAULT_STATUS: (prot: {2, 3}, clientId: 112, vmId: 1)
InterruptPacket(146, 10645516, 0, 0)
VM_CONTEXT1_PROTECTION_FAULT_ADDR: 0
VM_CONTEXT1_PROTECTION_FAULT_STATUS: (prot: {}, clientId: 0, vmId: 0)
InterruptPacket(146, 10645516, 0, 0)
VM_CONTEXT1_PROTECTION_FAULT_ADDR: 0x5000
VM_CONTEXT1_PROTECTION_FAULT_STATUS: (prot: {2, 3}, clientId: 112, vmId: 1)
InterruptPacket(146, 10645516, 0, 0)
VM_CONTEXT1_PROTECTION_FAULT_ADDR: 0x5000
VM_CONTEXT1_PROTECTION_FAULT_STATUS: (prot: {2, 3}, clientId: 112, vmId: 1)
InterruptPacket(146, 10645516, 0, 0)
VM_CONTEXT1_PROTECTION_FAULT_ADDR: 0
VM_CONTEXT1_PROTECTION_FAULT_STATUS: (prot: {}, clientId: 0, vmId: 0)
HDP flush problem?
2 Likes
Huge progress, kalisti5 is your kms guy.
Again, massive achievement here
So app_server is being rendered here by the Radeon? Whereas before it was rendering with the onboard graphics and you were only using the Radeon to render the Vulcan example?
app_server use UEFI framebuffer driver, but RadeonGfx is started later and it keeps mode set by UEFI GOP. Rendered content is still presented with software app_server path.
In theory RadeonGfx can already control framebuffer memory, buffer flipping and vsync.
It is currently something wrong with radeon_hd HDMI modesetting, maybe PLL related (#17461).
Onboard Intel GPU do not work if external GPU is selected in BIOS. It probably need to be fully initialized by driver.
11 Likes
I managed to setup different framebuffer for second monitor. Both monitors are connected to Radeon GPU (center monitor to DVI and smaller right to HDMI, left is a tablet PC and unrelated). I also managed to setup interrupts for vsync and page flip (counters are visible on photo). Interrupts are currently a bit not real, pooling timer is used, proper interrupt handling need forwarding interrupts from kernel. Radeon GPU use a ring buffer for interrupts that store interrupt packets with event ID and parameters. Mode setting is still done by UEFI GOP.
It will be possible to provide VideoStreams BufferConsumer interface from RadeonGfx and render something to second monitor (not implemented yet).
33 Likes
Very nice. Do you want a desktop and desktop card now ???
I love reading the progress of X512.
We all cheer for you, and I think it’s something beyond the hope of having 3D acceleration that we can use for our personal use someday (we already have this on other OSes), it’s seeing Haiku’s growth contribution that is thrilling.
11 Likes
Connection with VideoStreams is working. VideoFileProducer was used for test.
41 Likes
RadeonGfx and VideoStreams present sequence:
12 Likes
I haven’t been in the dics in a long time but do you see anything about audio ring and latency data for stream alignment. HDMI audio has been a long held dream.
1 Like
I have seen some HDMI audio CRTC registers, but not tried to experiment with them yet. My monitor supports HDMI audio, it has internal speakers and analog audio output jack.
7 Likes
We are all grateful for the efforts, afaik the radeon cards use the hda codec, so it’s always been a mattee of pulling the info from atombios to set up the routing
2 Likes
I implemented real interrupt handling and now interrupts can be handled without pooling timer. Interrupts are used for various events like command buffers completion, screen buffer flipping, display hotplug, GPU memory page faults etc… This also solved USB problem when USB started trigger errors and unmount boot disk after some time when GPU interrupt is triggered. USB and GPU probably share the same legacy PCI interrupt pin.
On kernel side I mostly copied intel_extreme vblank interrupt handling code with semaphore. On userland side RadeonGfx run interrupt watcher thread that acquire interrupt semaphore and call interrupt ring dispatch.
19 Likes
Some update about speed If I may ask?
1 Like
Begging your pardon andreas_dr, but why does x512 have to do a benchmark every time he adds a little plumbing? He may not even be to the optimizing stage of development yet. Premature optimization is the root of many kinds of evil. Let him get all the plumbing added first, then see about speeding it up.
1 Like
Just asking because super excited and curious. x512 does not need to answer and I asked politely, so I see no issue here 
2 Likes
I’m excited too. I just want the job done right. 
1 Like
No significant difference. The speed problem is probably related to some wrong initialization.
I checked Linux and it seems to unable to preempt command execution, at least for this GPU. So if you run fast and slow program, everything including GUI will be slow. RadeonGfx execution scheduling do not significantly differs from Linux in terms of performance.
9 Likes