#15575 closed task (invalid)
Move BGLView implementation from mesa to Haiku repository
Reported by: | X512 | Owned by: | kallisti5 |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Kits/OpenGL Kit | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev53644.
Currently Haiku OpenGL kit (libGL.so) is located completly in mesa package. BGLView implementation is unrelated to mesa and shoud be moved to Haiku repository. OpenGL driver implementation (Software Pipe) may still be located in mesa package.
Change History (15)
comment:1 by , 5 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 5 years ago
BGLView is just wrapper around OpenGL add-on and calls BGLRenderer interface implemented inside add-on. Where does it depend on Mesa?
comment:3 by , 5 years ago
BGLRenderer is not a real Be or Haiku class (there is no header file for it, even in "private", in Haiku); it is actually a Mesa HGL (Haiku GL) class kallisti5 named. So, that is precisely how it depends on Mesa.
comment:4 by , 5 years ago
BGLRenderer interface is mostly same as BGLView, it do not depend on Mesa architecture. Third-party OpenGL drivers should be also supported. Video card vendors may provide OpenGL/Vulkan/etc. drivers. So Haiku should have standard OpenGL driver interface someday.
follow-up: 7 comment:5 by , 5 years ago
Having BGLView in Haiku and the rest of the code in Mesa creates useless strong coupling between Haiku and Mesa versions. When BGLView is in Mesa, we can easily switch Mesa versions of even completely replace Mesa with something else. For example, TinyGL provides an ABI compatible replacement for BGLView that you can use if you want.
So, this should stay as it is now.
Also, how would we build libGL.so from sources that are partly in Mesa, and partly in Haiku? This clearly can't work. So Mesa would have to provide a partial libGL and Haiku would have to relink it and add more things to it? It is making things more complicated for no reason.
comment:6 by , 5 years ago
I mean that LibGL implementation will provide abstract add-on API and not depend on any implementation. Add-on can be implemented by Mesa, TinyGL, hardware accelerated driver etc.
Currently BGLRenderer is Mesa independent except GLDispatcher. GLDispatcher can be removed and GetGLProcAddress function can be added to BGLRenderer. Then BGLRenderer can be made official OpenGL diriver API.
comment:7 by , 5 years ago
Replying to pulkomandy:
Also, how would we build libGL.so from sources that are partly in Mesa, and partly in Haiku?
Of course libGL.so will not have any Mesa parts, only add-on management system.
comment:8 by , 5 years ago
Also Haiku dependent parts in Mesa can be removed and driver can be implemented by OSMesa interface (https://www.mesa3d.org/osmesa.html).
follow-up: 11 comment:9 by , 5 years ago
The official interface to libGL in Haiku is BGLView. Any implementation of OpenGL for Haiku must provide its own implementation of BGLView. Mesa provides one, TinyGL provides another, rudolfc's old accelerated driver for NVidia cards based on utahglx provides a third.
There is no way these different BGLView implementations can be merged together, they are different implementations, and there is no point in an extra indirection level. Each version of libGL provides a common interface, and that interface is BGLView. There is no need for an add-on management system here.
comment:10 by , 5 years ago
It that case how I can replace OpenGL implementation without uninstalling all packages depending on libGL.so?
comment:11 by , 5 years ago
Replying to pulkomandy:
There is no way these different BGLView implementations can be merged together, they are different implementations, and there is no point in an extra indirection level.
Add-on management system can be used for automatic driver selection. If no user driver installed or safe mode enabled, default driver will be used. If user install driver better than default, system will use that driver. Driver selection may depend on BGLView initialization options.
follow-up: 13 comment:12 by , 5 years ago
It that case how I can replace OpenGL implementation without uninstalling all packages depending on libGL.so?
Two ways: 1. Rebuild Mesa package, and install your new one to replace the old one. 2. Blacklist just the libGL.so from the Mesa package, and put your own in non-packaged/lib.
comment:13 by , 5 years ago
Replying to waddlesplash:
Two ways: 1. Rebuild Mesa package, and install your new one to replace the old one. 2. Blacklist just the libGL.so from the Mesa package, and put your own in non-packaged/lib.
This will not work for another packages providing libGL.so like TinyGL as you mentioned.
comment:14 by , 5 years ago
You install your alternative package that provides libGL.so (tinyGL does, as I mentionned already). Since the dependency is not on the package name but on the library name, this is transparent.
Try it for yourself, tinygl is available in haikudepot already. Once you have tinygl installed, you can remove mesa and no app will complain.
comment:15 by , 2 years ago
Experimental implementation with GLVND and EGL: https://github.com/X547/libglvnd/tree/master/src/HGL.
The BGLView implementation used to be in master and was intentionally moved to the Mesa package, as it heavily depends on the Mesa version used. This way the Mesa version can be cleanly changed without disrupting master so much.