Mesa 21.0 Is Now Working With Haiku OS For Software OpenGL Rendering

[genukie]

Can confirm working, trialed and errored over 10 ubuntu installs haha with random kernel mods here and there. But at the end, i didnt have to make any changes to grub or the kernal. Just needed to add modprobe for si cik and add afew conf files for amdgpu

So i averaged 70-80fps low 50s and peak 98 on Unigine Heaven on ultra settings 8x analising at 1920x1080

---- System ----
System: Linux 5.8.0-50-generic x86_64
CPU: AMD A10-5750M APU with Radeon(tm) HD Graphics 2495MHz MMX+ SSE SSE2 SSE3 SSSE3 SSE41 SSE42 SSE4A SSE5 AVX HTT x4
GPU: Unknown GPU x1
System memory: 13937 MB
Video memory: 256 MB
Sync threads: 3
Async threads: 4

---- MathLib ----
Set SSE2 simd processor

---- Sound ----
Renderer: OpenAL Soft
OpenAL vendor: OpenAL Community
OpenAL renderer: OpenAL Soft
OpenAL version: 1.1 ALSOFT 1.19.1
Found AL_EXT_LINEAR_DISTANCE
Found AL_EXT_OFFSET
Found ALC_EXT_EFX
Found EFX Filter
Found EFX Reverb
Found EAX Reverb
Found QUAD16 format
Found 51CHN16 format
Found 61CHN16 format
Found 71CHN16 format
Maximum sources: 256
Maximum effect slots: 16
Maximum auxiliary sends: 2

---- Render ----
GLRender::GLRender(): Unknown ATI GPU
OpenGL vendor: AMD
OpenGL renderer: AMD Radeon(TM) HD8970M (PITCAIRN, DRM 3.38.0, 5.8.0-50-generic, LLVM 12.0.0)
OpenGL version: 4.6 (Core Profile) Mesa 21.2.0-devel (git-a165385 2021-04-17 focal-oibaf-ppa)
OpenGL flags: Core Profile
Found required GL_ARB_map_buffer_range
Found required GL_ARB_vertex_array_object
Found required GL_ARB_draw_instanced
Found required GL_ARB_draw_elements_base_vertex
Found required GL_ARB_transform_feedback
Found required GL_ARB_half_float_vertex
Found required GL_ARB_half_float_pixel
Found required GL_ARB_framebuffer_object
Found required GL_ARB_texture_multisample
Found required GL_ARB_uniform_buffer_object
Found required GL_ARB_geometry_shader4
Found optional GL_ARB_blend_func_extended
Found optional GL_ARB_tessellation_shader
Found optional GL_ARB_shader_bit_encoding
Found optional GL_ARB_sample_shading
Found optional GL_ARB_compute_shader
Found optional GL_ARB_gpu_shader5
Found optional GL_EXT_texture_compression_s3tc
Found optional GL_ARB_texture_compression_rgtc
Shading language: 4.60
Maximum texture size: 16384
Maximum texture units: 192
Maximum texture renders: 8

---- Physics ----
Physics: Multi-threaded

[baryluk]

They're likely referring to the "read-only" nature of it.
Essentially our system directories are read-only. Every software package is "mounted over" the system directories read-only.

In linux terms, /usr /bin /lib are read-only. You can't modify them.
We expect you to use /usr/local, /usr/local/bin, /usr/local/lib, etc.
The "local" paths (we call them "non-packaged") override the system ones.


I hated it at first as well... but to be honest, from a security standpoint it's awesome. As the edge cases have been fixed (forgetting to check non-packaged/lib first, etc) it's actually panned out to be a great design.

It is reminiscent of Amiga OS design.

And there are some approaches on Unix to try similar. Most notably Guix and NixOS. Which approach to software installation I really really like.

[gilboa]

Does Haiku support SMP and 64-bit? That would help with software renderer quite a bit.

Yes and yes.

[gilboa]

They're likely referring to the "read-only" nature of it.
Essentially our system directories are read-only. Every software package is "mounted over" the system directories read-only.

In linux terms, /usr /bin /lib are read-only. You can't modify them.
We expect you to use /usr/local, /usr/local/bin, /usr/local/lib, etc.
The "local" paths (we call them "non-packaged") override the system ones.


I hated it at first as well... but to be honest, from a security standpoint it's awesome. As the edge cases have been fixed (forgetting to check non-packaged/lib first, etc) it's actually panned out to be a great design.

First things first, many thanks for your hard work on Haiku. While I only play with it from time to time on a VM, but I must admit I'm extremely impressed by the huge steps taken by Haiku to make it a viable daily driver since B1.

Per your post, I too found the package manager a bit odd at first, coming from the world of RPM and DEB. But after a while, it simply works. And as you said, from a security standpoint the ideal read-only FS used by packages is very compelling.

- Gilboa

[baryluk]

Nice. I remember running this teapot demo on BeOS back in a day, around 2000.

Does Haiku support SMP and 64-bit? That would help with software renderer quite a bit.

[kallisti5]

Their package manager is indeed different.
But intrusive? Care to elaborate?

BTW, I've got a 64bit Haiku VM (trunk) that I play around with for the past 2+ years. It has it warts and all, but I can't say that I have any issues with the package manager ...

They're likely referring to the "read-only" nature of it.
Essentially our system directories are read-only. Every software package is "mounted over" the system directories read-only.

In linux terms, /usr /bin /lib are read-only. You can't modify them.
We expect you to use /usr/local, /usr/local/bin, /usr/local/lib, etc.
The "local" paths (we call them "non-packaged") override the system ones.


I hated it at first as well... but to be honest, from a security standpoint it's awesome. As the edge cases have been fixed (forgetting to check non-packaged/lib first, etc) it's actually panned out to be a great design.

[gilboa]

In any case the package management system is so badly designed and intrusive into the basic usage of the filesystem... that I would never suggest anyone use it.

Their package manager is indeed different.
But intrusive? Care to elaborate?

BTW, I've got a 64bit Haiku VM (trunk) that I play around with for the past 2+ years. It has it warts and all, but I can't say that I have any issues with the package manager ...

[cb88]

They already import FreeBSD drivers.

Different drivers. Network drivers != graphics drivers.

The hardware graphics driver development on Haiku sputters every few years and then dies out as developers loose interest or squat on it deterring interest of other developers because they think someone is working on it. The safest assumption at this point is that nobody is working on it untill they publish working code.

In any case the package management system is so badly designed and intrusive into the basic usage of the filesystem... that I would never suggest anyone use it.

[microcode]

It is often a lot faster that Linux. Not sure about the system calls interface, but the GUI is something you either love or hate. I personally love it

If only Vivaldi browser was available for Haiku, then I would switch to it full-time

For me it is BeOS nostalgia that makes Haiku cool to me. I think that probably they could really run with this and have an advantage in performance that other systems don't have. A lot of cycles are wasted in GNOME and KDE trying to figure out how to draw decorations and such, which don't need to be wasted when you just want it to look like BeOS forever.

[topolinik]

It is often a lot faster that Linux.

I feel it's more than this.
The small dev team, they care so much about good efficient code they make linux installations seem as the bloated mess Windows appeared when compared to the early GNU/linux distributions in the late '90s.