Announcement

Collapse
No announcement yet.

Open-Source GPU Drivers Causing Headaches In KDE 4.5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • smitty3268
    replied
    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.

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:


  • deanjo
    replied
    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.

    Leave a comment:


  • marek
    replied
    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.

    Leave a comment:


  • BlackStar
    replied
    And a slightly off-topic question: does Mesa implement the noise*() functions for GLSL?

    Leave a comment:


  • BlackStar
    replied
    Originally posted by marek View Post
    DDX and DDY are already in GLSL 1.1.
    Oops, just checked the specs and you are right. Although I kinda question their usefulness, since you 1.1 doesn't offer texture*Grad functions.

    Fake edit to my previous post:
    - "in" and "varying" should obviously be "in" and "out"
    - texture*Lod should be texture*Grad. The former exists since GLSL 1.1 (maybe earlier) and allows you to select the mipmap level, but it's the latter that allows you to specify the gradients explicitly (necessary for artifact-free parallax mapping, for instance).

    Leave a comment:


  • marek
    replied
    Originally posted by BlackStar View Post
    GLSL 1.3 renames the "attribute" and "varying" keywords to "in" and "varying", respectively, in order to make room for more shader stages (geometry, etc). It also introduces derivatives (ddx, ddy), a few new texture functions (texture*lod that allows you to control the mipmap it samples from), deprecates built-in uniforms, modifies the syntax for fragment output for easier MRT and adds a couple of new keywords (meant for OpenGL ES compatibility).
    DDX and DDY are already in GLSL 1.1.

    Leave a comment:


  • darkbasic
    replied
    Well, with radeon (R600c/g) and mesa git I even didn't noticed they raised the opengl requisites. It just worked.
    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!

    Leave a comment:


  • BlackStar
    replied
    Originally posted by V!NCENT View Post
    What's the difference between GLSL 1.2 and 1.3? I'm simply guessing that's why they are going OpenGL 3?
    GLSL 1.3 renames the "attribute" and "varying" keywords to "in" and "varying", respectively, in order to make room for more shader stages (geometry, etc). It also introduces derivatives (ddx, ddy), a few new texture functions (texture*lod that allows you to control the mipmap it samples from), deprecates built-in uniforms, modifies the syntax for fragment output for easier MRT and adds a couple of new keywords (meant for OpenGL ES compatibility).

    Again, none of those features is necessary - or even useful - to desktop composition. I can understand kwin wanting a GL3-compatible codebase for future work but I will be very surprised if it offers any new functionality (over GL2) in the immediate future. I certainly cannot see them dropping 50% of their user-base for no tangible benefit.

    Leave a comment:


  • V!NCENT
    replied
    What's the difference between GLSL 1.2 and 1.3? I'm simply guessing that's why they are going OpenGL 3?

    Leave a comment:

Working...
X