You know, running the numbers, it seems that with each Mesa release we're getting further away from being up-to-date with the latest OpenGL spec, which is surprising and a bit scary. Comparing the difference between the release times of the OpenGL specs and the Mesa versions that support them, Mesa 4 was 0.2 years late, Mesa 5 was 0.3 years late, Mesa 6 was 0.4 years late, Mesa 7 was 1 year late, Mesa 8 was 3.5 years late, Mesa 9 was also 3.5 years late, and now Mesa 10 is 3.6 years late... Hopefully this trend can be reversed at some point.
Announcement
Collapse
No announcement yet.
What Do You Wish Was In Mesa 10.0?
Collapse
X
-
Originally posted by DrYak View PostBetter design a simple API exposing what's necessary (just like RandR exposes mode-settings).
A DBUS interface would be perfect, and let the various local solution tap into it (like KDE's Kscreen and battery widget, etc.)
Even if it was all done inside the same company 3DFx had a similar approach for their windows drivers:
- the low-level driver, when installed by it's .INF uploads a bunch of info into the registry.
- the end-user configuration software, reads the registry and draws drop-down menus and horizontal bars to let the user change settings. These graphical edits will change variables as defined in the registry by the low-level installer.
So if you want to hack the drivers to create new settings or new mode sets, just edit the .INF file so it creates new entries in the registry, and the conf application will automagically show you newest creation.
xdriinfo options 0
(insert obligatory note how dbus deserves a painful death, so much so that even XML is superior)
Comment
-
Originally posted by DrYak View PostWell, 3dfx did back on windows during 199-something. Of course back then, it was just limited to one driver talking over dbus to one end-user application. (Well actually not only one. There was a small cottage industry of people making "optimised" drivers with different settings in .INF, and other people making "nicier" configuration app, than the default, all talking through the same registry. So in the end, you ended up with loads of applications and drivers, except they all were for pieces of hardware from the same constructor, and more or less using similar drivers binaries (or binaries compiled from the same small pool of few available codebases (?) ) ).
Now we are in 2013, so I think having an open standard to be followed by all opensource mesa drivers(*) and that could be used by all compatible applications.
The same way that RANDR exposes a unified API to mode setting and multi-monitors, and can be used with lots of applications ranging from pure command line (xrandr, useful to retake control remotely of a machine with a b0rked screen configratuion, whitout losing applications) all the way to nicely integrated applets inside desktop environments. (KScreen is nicely integrated inside KDE, providing a continuty in end-user experience).
(*): ...and after while probably also by AMD's Catalyst, given their track of eventually implementing the standard too, while Nvidia focuses on their approach of "we only do the same thing as Windows". Some on-camera cussing by Linus may be required before they move their asses.
(?): - DirectX driver was kept binary-only for the most of the lifetime of the parent company, though a few managed to get a copy of the code base and provide patched/fixed builds after 3dfx got acquired by Nvidia. For the rest, most of the "custom" drivers simply repackaged the official binaries with only very rare binary patches.
- Glide proprietary API has always been binary on windows. Gut later in it's life 3dfx opensourced its linux implementation, meaning the latest Windows drivers could actually contain recompiled glide drivers from the linux code base.
- OpenGL: huge complicated mess. At the beginning 3dfx didn't provide any openGL support, only mini drivers, small "extra-light" libraries that only implemented a very small subset of openGL API, only the bare minimum to get games running, all done by calling into Glide for the actual rendering. As more games started to use OpenGL, 3dfx developed further these "miniGL" to support newer games. Eventually, they released a full ICD. Which later got "hidden surface removal" capabilities (accelerates by only drawing visible portions of polygons, but very buggy leading to missed frames and glitches at more aggressive settings). All this was binary only. Meanwhile, Mesa3D had a nice full openGL implementation that ran also using Glide for the actual rendering (and was even available on MS-DOS, in addition to Linux and Windows). Although a little bit slower than the official Windows drivers, this got progressively more and more popular, specially since later versions got faster and covered more openGL API. Thus Mesa became the better alternative to play game released later thank to better openGL API (Mesa was capable to play Doom3 at reduced quality even if 3dfx lacked the necessary hardware for some shading) and less bugs (specially vs. HSR).
In a way the life expectancy of Voodoo hardware was greatly extended thanks to opensource: 3dfx' own glide, and mesa's opengl implementation.
Comment
-
Originally posted by duby229 View PostYour experience with 3dfx is impressive. I had never owned a voodoo card. My first video card was a rage3d. since then I've been through dozens of ATi cards. They too had some difficulty with opengl at first. Realize that it was nVidia that pushed opengl so hard. This was at a time when they were having problems with D3d which was what MS was pushing hard for. Opengl exists today in the state that it does because of nVidia.
OpenGL exists because of thats what engineering workstation use... Games do use it but it was not the games industry that pushed its initial development. The workstation industry has also held its development back in recent times due to the fact that compatibility was more important for them than progress.
OpenGL has its origins at SGI... Nvidia and AMD both have made large contributions to it through the OpenGL ARB group since 1992. Improvements now come through Kronos... which replaced/absorbed the ARB.Last edited by cb88; 27 October 2013, 04:29 PM.
Comment
-
Originally posted by GreatEmerald View PostYou know, running the numbers, it seems that with each Mesa release we're getting further away from being up-to-date with the latest OpenGL spec, which is surprising and a bit scary. Comparing the difference between the release times of the OpenGL specs and the Mesa versions that support them, Mesa 4 was 0.2 years late, Mesa 5 was 0.3 years late, Mesa 6 was 0.4 years late, Mesa 7 was 1 year late, Mesa 8 was 3.5 years late, Mesa 9 was also 3.5 years late, and now Mesa 10 is 3.6 years late... Hopefully this trend can be reversed at some point.
I am under the impression that OpenGL has had a slow evolution for a while (to quote another post:Originally posted by cb88 View PostThe workstation industry has also held its development back in recent times due to the fact that compatibility was more important for them than progress.
OpenGL has its origins at SGI... Nvidia and AMD both have made large contributions to it through the OpenGL ARB group since 1992. Improvements now come through Kronos... which replaced/absorbed the ARB.
Specially there have been quite some delay before OpenGL 3.x and massive delays before OpenGL 4.x.
I am also under the impression that overall Mesa development *is* speeding up also. With more ressources poured in recently.
The "increasing gap" effect comes (in my opinion) more due to the fact that Mesa for a while used to be an almost-standing-still target, and has boomed not so long ago after much stagnation, and that Mesa ramped up development only very recently.
Comment
-
Originally posted by DrYak View PostIt would be interesting to make a time plot of it.
I am under the impression that OpenGL has had a slow evolution for a while (to quote another post
Specially there have been quite some delay before OpenGL 3.x and massive delays before OpenGL 4.x.
I am also under the impression that overall Mesa development *is* speeding up also. With more ressources poured in recently.
The "increasing gap" effect comes (in my opinion) more due to the fact that Mesa for a while used to be an almost-standing-still target, and has boomed not so long ago after much stagnation, and that Mesa ramped up development only very recently.
For Mesa, 4.0 and 4.1 are going to fall further behind their original release dates, but starting with 4.2 they might actually start catching up. They'd have until Feb/March of 2015 to get 4.2 out and stay on the current gap, and that seems reasonable. 4.3 support then might take a while after that, but they'd have a whole year to work just on that and avoid falling further behind.
Comment
-
Originally posted by GreatEmerald View PostYou know, running the numbers, it seems that with each Mesa release we're getting further away from being up-to-date with the latest OpenGL spec, which is surprising and a bit scary. Comparing the difference between the release times of the OpenGL specs and the Mesa versions that support them, Mesa 4 was 0.2 years late, Mesa 5 was 0.3 years late, Mesa 6 was 0.4 years late, Mesa 7 was 1 year late, Mesa 8 was 3.5 years late, Mesa 9 was also 3.5 years late, and now Mesa 10 is 3.6 years late... Hopefully this trend can be reversed at some point.
I'm hoping that the faster release cycle, plus the new developers that have come on-board in the past year, plus the urging/motivation from Valve and SteamOS, will all hasten a speedier release schedule and maybe we can see parity within the next year.
Comment
-
Originally posted by DrYak View PostSpecially there have been quite some delay before OpenGL 3.x and massive delays before OpenGL 4.x.
Comment
-
Originally posted by GreatEmerald View PostYou know, running the numbers, it seems that with each Mesa release we're getting further away from being up-to-date with the latest OpenGL spec, which is surprising and a bit scary. Comparing the difference between the release times of the OpenGL specs and the Mesa versions that support them, Mesa 4 was 0.2 years late, Mesa 5 was 0.3 years late, Mesa 6 was 0.4 years late, Mesa 7 was 1 year late, Mesa 8 was 3.5 years late, Mesa 9 was also 3.5 years late, and now Mesa 10 is 3.6 years late... Hopefully this trend can be reversed at some point.
Comment
-
I am not so shure about that, like I said many stuff in the driver stack got changed in the last year the biggest ist the switch to gallium3d. And not only the switch also the supporting of both drivers.
So there are now 2 things that happend :
1. at some point new features will only come to the gallium3d driver, so not double the work, I think that did happen already for radeon at least?
2. one of the main features gallium3d has is the abstraction between a small core of drivers and the feature-state trackers, like we got some idea when we saw the directx or direct3d state trackers. So in theory it should now be possible to implement feature xy in a mesa-statetracker (is this the name for it?) and only few or none changes would be needed in the driver part. So you do more work 1 time instead of multiple times.
The driver-devs I heard from said that they did something like a windows 98 to windows 7 driver architecture update in a few years, so in that time of such a change of course infrastructure-work will take much resources.
Comment
Comment