Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: What Do You Wish Was In Mesa 10.0?

  1. #11
    Join Date
    Sep 2013
    Location
    Germany
    Posts
    46

    Default

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

  2. #12
    Join Date
    Sep 2008
    Posts
    40

    Default

    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.

  3. #13

    Default

    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

  4. #14
    Join Date
    Sep 2013
    Posts
    250

    Default

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

  5. #15
    Join Date
    Sep 2012
    Posts
    298

    Default

    Quote Originally Posted by oibaf View Post
    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.

  6. #16
    Join Date
    Apr 2008
    Posts
    184

    Default

    Quote Originally Posted by blackiwid View Post
    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.

  7. #17
    Join Date
    Nov 2007
    Posts
    1,355

    Default

    Quote Originally Posted by DrYak View Post

    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.

  8. #18
    Join Date
    Jul 2012
    Posts
    55

    Default

    Opengl es 3 support.

  9. #19

    Default

    Quote Originally Posted by toyotabedzrock View Post
    Opengl es 3 support.
    Mesa already has ES 3.0 support.

    http://www.phoronix.com/scan.php?pag...tem&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.

  10. #20
    Join Date
    Apr 2008
    Posts
    184

    Default

    Quote Originally Posted by duby229 View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •