What Do You Wish Was In Mesa 10.0?

[theghost]

I have only one wish, plz finally fix the GPU hangs for Sandybridge: https://bugs.freedesktop.org/show_bug.cgi?id=54226

[tom.higgy]

Another vote for the OpenCL stuff here, although I guess that's still useful for most applications. That's the only thing I ever switch back to Catalyst for these days.

Finishing up OpenGL 3.2/3.3 support in r600g and improving performance is the other thing I'd really like to see. Otherwise, I find it's mostly good enough for my purposes.

[oibaf]

Here is an almost 3 year performance problem with a patch available since more than 2 year but still waiting:

https://bugs.freedesktop.org/show_bug.cgi?id=34495

And this is a more recent corruption issue again with a patch available:

https://bugs.freedesktop.org/show_bug.cgi?id=68503

[_SXX_]

Really want to see better performance for Cayman GPUs.
Currently HD6950 sometimes have worse performance than HD6850.

[wargames]

Here is an almost 3 year performance problem with a patch available since more than 2 year but still waiting:

https://bugs.freedesktop.org/show_bug.cgi?id=34495

I used to have that problem, but as the last comment says, it has been fixed in mesa 9.2.

[DrYak]

I dont think such a gui thing should be have a high priority. Dont waste developer time by doing such stuff, supporting more opengl-levels getting more speed etc fixing more bugs... is way more important.
{...}
For randr canonical gnome and others made their stuff like they wanted. So why not the same approach for mesa stuff?

I agree that making a full fledged GUI configurator would be a waste of development ressource, and in addition the end result would probably badly integrated into the environment and might even suffer usability issue (Mesa are low-level ?ber-wizards. Absolutely great programming skills, but maybe not the skill-set necessary for a user-facing tool).

Better 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.

[duby229]

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.

I do like your idea about dbus, but this thing about dumping stuff into a registry seems like it could only work if that driver and its support applications used it. If it was a general registry that anything could treat in such a way.....well.... you know what I'm saying.

[toyotabedzrock]

Opengl es 3 support.

[halfmanhalfamazing]

Opengl es 3 support.

Mesa already has ES 3.0 support.

http://www.phoronix.com/scan.php?page=news_item&px=MTMwMDg

OpenGL ES 3.0 support is merged into Mesa for the 9.1 release due out later this month and Intel tested this code in conjunction with the Linux 3.6 kernel for their conformance results.

[DrYak]

I do like your idea about dbus, but this thing about dumping stuff into a registry seems like it could only work if that driver and its support applications used it. If it was a general registry that anything could treat in such a way.....well.... you know what I'm saying.

Well, 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.