NeXT (now Apple) was the first to do multi-arch binaries. They had more than two: HP/UX, Intel, Motorola 68k and SUN Spark. When an application is installed you can select what architecture should be used and that would be installed only. With Apple’s move from PPC to Intel and then to ARM, Rosetta/macOS needs to have two architectures installed to migrate from one architecture to another with zero configuration, just install and go.
Porting the new “open source nvidia drivers” are a good idea at least for the modern nvidia like 1060 or something like that.
For me the best thing i can wish is a good failsafe mode (at least for graphics) and resolve some problems with bootmanagers from 5 different mainboards i have different results including reboots, not taken to GUI(screen of KDL) and different behaviors.
Beta4 is almost ready for release. Drivers for nVidia didn’t make the cut. Nor did Radeon nor discrete Intel. I think the graphics acceleration implementation was pushed back from release 1 to release 1.1 in the milestones on the bug tracker. Graphic acceleration is presently only implemented in RISC-V because fallbacks were unavailable on that platform, I think.
What is implemented is the “LavaPipe” Vulkan software implementation. It’s on HaikuPorts already. The next version of Mesa should have the Zync (or similarly named) patch to reroute the OpenGL support through LavaPipe. This should make the software 3D implementation faster through parallel processing. This also should clear the way for software to directly interface to future Vulkan drivers. Cards too old to support Vulkan will be doomed to run software through LavaPipe until they can be replaced.
It was not pushed back, it never was part of the plans for R1.
There is no graphics acceleration anywhere. On RISC-V we use the framebuffer driver with UEFI, just like we do on PC.
Mesa already does parallel processing. Just run any app using OpenGL and you will see all your CPU cores are put to use.
2 Likes
Uhhh, why would I run my opengl software through a translation layer on vulcen emulation on opengl capable cards.
I fail to see any benefit over the current way of just using software opengl now. It would be nice to habe opengl drivers and not ask 90% of the userbase to throw sway their gpus and laptops because “vulcan cool”
2 Likes
The reason Vulkan drivers were adopted throughout the industry was their ability to take advantage of multithreading. That’s also a central theme of Haiku. When looking at OpenGL, its static context stands in the way of using the CPU cores to their fullest potential.
When the PlayStation 3 came out, its devkit supported OpenGL-ES2 instead of OpenGL. It turns out that the context -free design of ES2 was better able to take advantage of stream processors and parallelism than the desktop OpenGL variant.
@PulkoMandy I shouldn’t have assumed a consensus of agreement that acceleration was originally a requirement of R1. Perhaps that will afford more time to discuss how the drivers should be implemented when they come.
If this begs more discussion, maybe splitting this thread from my previous post onward and putting these posts in a thread about graphics acceleration would be justifiable to avoid thread pollution.
That seems a strange idea, since the goal of OpenGL is to have the CPU doing little to no work, and the GPU doing the heavy lifting ot he 3D rendering. Why would you need several CPU cores just to send things to the GPU?
The PS3 is a very specific and exotic hardware (as were most previous gaming consoles). This approach failed and now they have an architecture much more similar to PCs. There must be a reason for this, maybe it is because the PS3 was extremely hard to develop for and did not get much of an advantage over simpler solutions to compensate?
Are we going to have yet another discussion about 3D acceleration?
- It is not planned for R1 and never was,
- We will see how it’s implemented whenever someone implements it. Could be OpenGL, could be Vulkan, could be Glide on Voodoo II cards only, just to annoy people and make a good april’s fool news item,
- It will probably be limited to some subset of hardware at least at first, but which hardware depends on who writes the code and what technology they chose,
- The most advanced efforts were rudolfc’s one based on UtahGLX (but that was a long time ago and not useful for modern hardware) and more recently X512’s prototype which is not yet fully integrated, for Radeon hardware.
Saying anything more requires a crystal ball to look into the future.
3 Likes
Ok. No further need for discussion on graphics acceleration until there is something to show.
posible thinks:
improve password widget in wifi textarea for show/hide password
in the linux world each distribution with each new release have new wallpaper set, maybe haiku have too, but like linux mint have wallpapers sorted by releases, and i dont like photos i prefer abstract artwork.
i test haiku often but i do not have installed now, i want ask for hpw to mount synology nas sambaa shares, its this command like and aafter see disk icon on desktop?
You can install… FuseSMB (or SMB Fuse?) from HaikuDepot. But it needs a lot of work or fiddling to get it to work with Synology. It works great for my ancient Netgear NAS, in the opening the icon and going into WORKGROUP will show that NAS, but nothing else. I suspect it has to do with the Samba version it’s running, even though I can set my Synology to use SMB 1 through 3.
Once you install it, though, you can edit the cache file with the name of your NAS and a share point, and it’ll show up and be usable until Fuse SMB scans again, when the cache will be overwritten. I’ve tried editing the config file, but it doesn’t seem to do anything.
I guess for my “Beta 4 Wishlist”, I would want a working, up to date, Samba.
1 Like
MrEntropy thanks i think samba is very important for modern systems
1 Like
I would like to ask about security:
Is it possible in the assembly, or in the same beta, to make some minimum possible control threshold through third-party channels, pulling out registers (on the legs of multicontrollers and buses) so that there would be minimal access to the zero area from externally these are at least the same configurations with rights “out of the box”, with the ability to safely boot from the same box. For example, the rights to all possible directories/files 400?..
And what’s interesting, lately I don’t watch the news at all, how are things with i2c, and will there be thoughts in that direction with access restriction?
rendant plus difficile l’accès d’un attaquant
Ref: #9919 (Haiku needs a hardware rendering pipeline / API for Mesa3D) – Haiku (haiku-os.org)
Proposed 9 years ago.
About PlayStation - back around the days of IBM Cell and Hitachi SuperH, most gaming devs didn’t wantto use certain “locked down” methods - especially dealing with SIMD-type usage - if the gains were minimal overall.
On your note of the accelerated drivers - you’d want the key components in place to port either an existing open-source OEM-supported driver (i.e. amdgpu (22.x)) or a ‘native’ driver… (yo’d want OEM developer support for a streamlined ‘native’ effort)…
Thanks for the link! I’ll move the discussion there.