Hey, as waddlesplash pointed out, my problem is not using efi, but instead trying to legacy boot - I don’t even make it as far as being able to use safemode using legacy booting.
Yes, we are saying that you need to use a 64-bit Haiku and EFI boot, this works under Ryzen (I do it all the time on my new machine.)
To be fair… that is a bug that should be fixed.
There is a ticket #16482 (https://dev.haiku-os.org/ticket/16482#no1) and according to this ticket, there is no working for RX460/480 or even 580 only Device ID’s added. This is a needed to do.
Good day,
From Sept 2018, when the first Ryzen post was written until now, many things have changed in the Haiku universe.
Regarding Ryzen (only UEFI related):
- Mostly everything seems to work fine on B350M motherboards but the Realtek Gigabit ethernet, which is slow [17MB/s on Linux; 900KB/s on Haiku] (known issue)
- Radeon RX560 and RX570 still have to go on Framebuffer - blacklisting driver in the ‘kernel’ settings file (known issue)
- On multiboot, still no auto detecting of the hard drive with Haiku, have to manually select it. I set things so I can also choose the boot drive in BIOS, just in case GRUB turns nuts. (known issue)
Other than those, it’s been pretty stable so far. Compared to the first day I tried to install Haiku on BM back then… only the video safe mode option is needed.
Good work, Haiku devs!! Kudos!!
Regards,
RR
I’m running Haiku on 3700x, x570 (MSI Tomahawk + pci intel extreme net), nvme drives and other than Framebuffer driver and power save features, Haiku runs like a champ.
Like to see more feedback on these:
I recently installed haiku on bare metal and it was running nicely. The only significant issue that I faced was that I was stuck at max 1400x1050 res. And I couldn’t change it after boot from the screen app due to UEFI. There was no option for a 16:9 res in the boot menu and due to stretching reading text in the offered res was a bit hard.
@nephele recommended me to try enabling support for my RX 570 in the radeon_hd driver. I did that (there was already an entry for RX 470/480) and it seemed to work. I get a black screen if I try to use the 1920x1080 res but at least I am getting 1600x900. If I am correct, the radeon_hd driver doesn’t support the RX 500 series and we actually need to port amdgpu to add proper support for it (right?). But still ig something is better than nothing. Are there any known issues due to which the support for polaris and co was disabled in the driver in R1/beta5?
One more question, are there any accelerated user space drivers that I can use to run graphics intensive programs with hardware acceleration? I ran the gl teapot demo and it seems to run at the same fps as with cpu so I assume the application isn’t actually using the gpu?
If it almost works, why not investigate and fix the existing radeon_hd driver instead of starting over with a port of difficult to understand Linux code?
No, Haiku is all software rendering currently.
If it almost works, why not investigate and fix the existing radeon_hd driver instead of starting over with a port of difficult to understand Linux code?
I found this reddit post https://www.reddit.com/r/haikuOS/comments/107idge/haiku_now_is_hardware_accelerated_video_testing/. So, I thought that if there is some work already done to port this driver which is a new one and supports more recent GPUs then it might be a better idea to put the effort there. Though the last commit in the linked repo is 2 years ago and I don’t have any idea about it’s current state.
I would love to investigate this issue if someone can guide me. As I have mentioned earlier I don’t have any experience with this kind of kernel level things. So, am a bit scared that I can do something stupid and damage my GPU especially since this is a kernel space driver. GPUs are real costly here lol.
Kernel code is not that much different from user space code. So maybe it’s the right opportunity to dive into it
This accelerated rendering was a test by x512, but more work is needed before it can be put into production. And I’m not even sure it completely replaces the existing driver. Setting a video mode and doing 3D rendering are two quite different things, even if they are put together in the same chip on modern hardware.
It seems unlikely that you would damage any hardware while working on a driver. At worst, you will crash the kernel and have to reboot the machine.
I was planning to do some research on harfbuzz and the haiku app server code. But there is still some time left for GSOC and this stuff is too exciting to resist so ig I will dive.
I was reading some of the driver code a few days ago after nephele first told me about this. Actually, the thing is that this driver only seems to support upto polaris 12 (RX 550/540/etc) and my gpu is polaris 20. Anyways, I am seeing what can I do. I will ask here and/or in IRC if I face any trouble.
Radeon_hd is even not fixed for an R9 380 4GB or and RX 580 8 Gb.
Can somebody kindly explain me the relevance of the various members of the display_timing struct and how is the refresh rate calculated from that? Here is the relevant struct: haiku/headers/os/add-ons/graphics/Accelerant.h at 30c9648a4fe3f6ddd5ab1aee2a682041613b9612 · haiku/haiku · GitHub.
Here is another link for people who prefer to avoid github links: Accelerant.h « graphics « add-ons « os « headers - haiku - Haiku's main repository
The refresh rate is the pixel clock divided by the total number of pixels.
So: refresh_rate = pixel_clock / (h_total * v_total)
The other fields are used to determine the video timings more finely.
Out of the total horizontal pixels (h_total), some are used for display (h_display), some are used for the synchronization pulse that tells the display when the line is complete (between h_sync_start and h_sync_end), and the remaining part (between h_display and h_sync_start and between h_sync_end and h_total) are there to leave some time for the display to end a line and start the next one.
Here is a picture that may help understanding it (maybe):
Usually these parameters should be defined according to the “generalized timing formula” Generalized Timing Formula - Wikipedia
Thank you for the detailed explanation. I was also doing some research on this. Most of the articles were quite confusing but then I came across https://www.ti.com/document-viewer/lit/html/SSZT622 which felt somewhat more simple and thorough than the others. I was confused about how can I actually calculate the blanking percentage (that article mentioned data sheets). But your explanation cleared that part.