Page 16 of 18 FirstFirst ... 61415161718 LastLast
Results 151 to 160 of 174

Thread: Open-Source GPU Drivers Causing Headaches In KDE 4.5

  1. #151
    Join Date
    Jan 2009
    Posts
    608

    Default

    Quote Originally Posted by BlackStar View Post
    And a slightly off-topic question: does Mesa implement the noise*() functions for GLSL?
    No, it doesn't, since proprietary drivers don't implement it either. A driver is allowed to return 0.5.

  2. #152
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by darkbasic View Post
    With the fucking intel driver it still doesn't work properly(and I'm using latest graphic stack from git). With latest stable intel driver I even cannot start kde to disable compositing!
    Log in without starting X, use nano or your favorite editor to open ~/.kde4/share/config/kwinrc, look for the section called [Compositing] and look for the line saying Enabled=true and change that to Enabled=false, reboot or start X and your in.

  3. #153
    Join Date
    Oct 2008
    Posts
    3,027

    Default

    Again, they are mostly concerned with getting a forward-compatible GL2 version working. That's so they can also run it on mobile devices, and get all the GLSL goodness that 2.0 brings.

    The 2 pieces of OpenGL 3 that were mentioned on his blog were:

    FBOs, which are already in the open drivers. Also, they have a wrapper around their use, so it transparently falls back on drivers which don't support them. (unless, of course, the drivers lie and simply crash)

    Geometry shaders - this sounded much more speculative, and would likely only be used in a couple fancy effects, accompanied with alternatives to run on older versions that might be slightly lower quality if necessary.

  4. #154
    Join Date
    Oct 2008
    Posts
    3,027

    Default

    Also, I should mention they aren't even 'requiring' the use of OpenGL2. That's what started this whole mess, is that they are trying to fallback to 1.x but failing because the drivers say they work with 2. They'll even fall further down into XRender and non-composited mode if they are able to detect problems, and that's the current issue.

  5. #155
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    There's a really simple but important point that is still being missed. When a driver is in development it is *going* to expose extensions & GL levels which work in some cases but not others, since typically the exposed features *do* work for enough applications that users are better off having the features exposed.

    That suggests one of three approaches :

    - application developer communities using driver features known to be in development should coordinate with the driver development community to make sure they use GL features in ways which are known to work - or -

    - applications should avoid using driver features known to be in development (this isn't real practical) -or -

    - applications should provide a user option to choose between a couple of levels of driver feature usage

    The driver developers are working on the 4th option (finish working on GL 2.x) but getting through something as big as GL 2.x is going to take a year or two (although it started a while ago). The unfortunate reality is that GL versions have *not* historically aligned well with consumer hardware functionality, so "almost full" GL implementations are going to be a fact of life until all of the pre-GL 4 hardware has disappeared from the user base.

    GL 3-ish hardware can usually run a full GL 2 implementation but there is a lot of very capable "not quite GL2" hardware in use today and for the forseeable future.

    Again, the problems here are probably a mix of systemic issues (described above) and good 'ol bugs. The only way I see to close the loop is for app developers to say "I'm doing X with the driver and expecting A, but I'm getting B instead", to which the driver developer will either say "oh crap, it's not supposed to do that" and try to fix the behaviour or will say "that's probably not going to work for you in the forseeable future, how about doing Y instead ?".

  6. #156
    Join Date
    Dec 2007
    Posts
    2,326

    Default

    Another thing to keep in mind: while certain GL specs may have been available for years, the support for them in mesa in many cases was only recently completed, or in others, is not complete yet. GL is a huge, often ugly API and it takes a lot of work to implement it properly.

    The GL 3.x and 4.x specs may be out but it will be a while before mesa (much less open drivers) gets support for them. And, while the GL 2.x and GLSL specs have been out for years, mesa has not supported them for that long. In fact the GLSL stack in mesa (which only supports GLSL 1.20 right now) is in massive flux at the moment.

    It seems to me that if the KDE developers want to target systems using open drivers they might want to at least get some sense of the current state of those drivers and the associated mesa stack.

  7. #157
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,126

    Default

    Quote Originally Posted by marek View Post
    No, it doesn't, since proprietary drivers don't implement it either. A driver is allowed to return 0.5.
    Fair enough!


  8. #158
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by BlackStar View Post
    Fair enough!

    x'D

    67890

  9. #159
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    Quote Originally Posted by marek View Post
    Give me a list of graphics techniques (requiring GL3) we should have in desktop effects. Then we can talk.
    I think that the only GL3 technique that has ever been mentioned in the context of desktop rendering were FBOs.

    Then some people blew it out of proportion.

  10. #160
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,385

    Default

    The main pushback from developers was more related to GL2 features. KDE developers are basically saying "if you expose the extension then it needs to be fully implemented" but that doesn't work from a driver development POV for a couple of reasons :

    - a lot of the target hardware does not fully support GL 2.x but is close enough for 95% of apps

    - most apps which require (and check for) GL 2 support only use a small subset of the capabilities of the extensions, so exposing features once they are sufficiently implemented to work for most apps is generally the most beneficial for users

    This doesn't make either side *wrong*, it just means that if they are both going to be working in the same area at the same time they probably should communicate more.

Tags for this Thread

Posting Permissions

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