Page 4 of 8 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 78

Thread: AMD, please give us EGL or decent direct rendering.

  1. #31
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Quote Originally Posted by Dandel View Post
    Yes, I do agree that having OpenGL ES/EGL working properly on ati drivers is really important. However, there's also other things that are "really really want" level. This is things like End users wanting what runs on Nvidia cards with Wine to also work on AMD/ATI cards.
    According to both bug reports Wine seems to be passing NaN to the driver for point size and the driver is returning GL_INVALID_VALUE, which presumably is different from what happens on the NVidia implementation.

    Behaviour when passing NaN to an OpenGL function is undefined IIRC, as long as the implementation does not crash, so I would argue that returning GL_INVALID_VALUE is perfectly legal and is probably the "most correct" behaviour.

    The winehq bug ticket has some discussion about a patch to intercept NaN values before they get to the driver; seems like the patch works in some place but not others, which suggests that the it is not blocking NaN under all conditions.
    Last edited by bridgman; 09-08-2011 at 07:05 PM.

  2. #32
    Join Date
    Oct 2007
    Posts
    321

    Default

    Quote Originally Posted by bridgman View Post
    According to both bug reports Wine seems to be passing NaN to the driver for point size and the driver is returning GL_INVALID_VALUE, which presumably is different from what happens on the NVidia implementation.

    Behaviour when passing NaN to an OpenGL function is undefined IIRC, as long as the implementation does not crash, so I would argue that returning GL_INVALID_VALUE is perfectly legal and is probably the "most correct" behaviour.

    The winehq bug ticket has some discussion about a patch to intercept NaN values before they get to the driver; seems like the patch works in some place but not others, which suggests that the it is not blocking NaN under all conditions.
    Yes, I do agree that the NaN behavior is probably correct for the most part, however, when you look at the functions on a per-function basis using the Khronos Man pages, the definition of glPointSize clearly states that GL_INVALID_VALUE is to be returned when the value is less than or equal to 0 (on OpenGL 2.1, 3.3, 4.1) and GL_INVALID_OPERATION when the call is made between begin/end. (OpenGL 2.1 only )

    anyways, the other bug with OpenGl has to do with the Occlusion query... for some reason ut3, and other games based on UE3 do not run correctly, or have serious performance problems.

  3. #33
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Quote Originally Posted by Dandel View Post
    Yes, I do agree that the NaN behavior is probably correct for the most part, however, when you look at the functions on a per-function basis using the Khronos Man pages, the definition of glPointSize clearly states that GL_INVALID_VALUE is to be returned when the value is less than or equal to 0 (on OpenGL 2.1, 3.3, 4.1) and GL_INVALID_OPERATION when the call is made between begin/end. (OpenGL 2.1 only )
    Yep. My understanding is that only the error logic specific to an OpenGL function is included in the per-function spec, not all of the general error conditions such as passing NaN (which is undefined for all OpenGL calls AFAIK). I've never been 100% sure of that though... fortunately I'm not one of the OpenGL architects

    Quote Originally Posted by Dandel View Post
    anyways, the other bug with OpenGl has to do with the Occlusion query... for some reason ut3, and other games based on UE3 do not run correctly, or have serious performance problems.
    I did a search for "occlusion", "unreal", "ut3" etc.. on the bug tracker and didn't find anything related to occlusion queries on fglrx, just ticket 54 about NaN / GL_INVALID_VALUE. Have you seen a related bug ticket on the tracker anywhere ?
    Last edited by bridgman; 09-08-2011 at 08:06 PM.

  4. #34
    Join Date
    Oct 2007
    Posts
    321

    Default

    Quote Originally Posted by bridgman View Post
    Yep. My understanding is that only the error logic specific to this OpenGL function is included here, not all of the general error conditions such as passing NaN (which is undefined for all OpenGL calls AFAIK). I've never been 100% sure of that though... fortunately I'm not one of the OpenGL architects



    I did a search for "occlusion", "unreal", "ut3" etc.. on the bug tracker and didn't find anything related to occlusion queries on fglrx, just ticket 54 about NaN / GL_INVALID_VALUE. Have you seen a related bug ticket on the tracker anywhere ?
    No, actually the bug that progressed on winehq is the most up to date... it appears that ut3 has problems due to occlusion queries giving the same output over and over again...

    see Comment 13 on winehq's bug report: http://bugs.winehq.org/show_bug.cgi?id=23048#c13

    there is some bug related to fglrx methods of handling the occlusion queries that causes unreal tournament 3 to have problems. I can also confirm with some tests that ut3 does not run at all with the current drivers. Currently when i test on a clean install the program simply does not render anything bug a black screen when using Catalyst 11.8. ( sabayon 6 latest updates)

  5. #35
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Quote Originally Posted by Dandel View Post
    No, actually the bug that progressed on winehq is the most up to date... it appears that ut3 has problems due to occlusion queries giving the same output over and over again...
    Thanks. I had looked at that log but rightly or wrongly my takeaway was "it's making the same call over and over again with the same parameters and getting the same result back each time, which makes sense". Presumably it's looking for a *different* result but no idea what result it's looking for or why it thinks the result it's getting is incorrect.

  6. #36
    Join Date
    Dec 2010
    Posts
    108

    Default

    Quote Originally Posted by entropy View Post
    Hum, is that any different from using the "System Settings" facility?

    System Settings -> Configure desktop effects -> Advanced

    If I check "Disable functionality checks" and "Enable direct rendering" I cannot
    see any performance degradation with direct rendering vs. indirect rendering.
    Because the setting is completely ignored and has been removed in master.

  7. #37
    Join Date
    Oct 2007
    Posts
    285

    Default

    Good to see that my attempt to improve this stuff is moving a bit

    One question though. bridgman, what are the plans to improve this? Could this be better with the next catalyst release? Please don't say years...

  8. #38
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    916

    Default

    Quote Originally Posted by mgraesslin View Post
    Because the setting is completely ignored and has been removed in master.
    Ok, thanks.

    On the other hand - why is it still there?
    Is it that there are some K* guidelines to forbid changing gui layouts in a bug fix release?
    I mean things like that might also give you woes in a bug report,
    when it's not perfectly clear to average joe (like me) what's actually going due settings being misinterpreted.

  9. #39
    Join Date
    Dec 2010
    Posts
    108

    Default

    On the other hand - why is it still there?
    because code had to be adjusted to ensure that everything works fine.

    I mean things like that might also give you woes in a bug report,
    when it's not perfectly clear to average joe (like me) what's actually going due settings being misinterpreted.
    That's why we fixed it. But we a very conservative about pushing changes into the branches. Only clear bug fixes go into the branch. Changes to the behavior (this is one) are going only into feature releases and code which would cause a regression can only go into feature releases. Removing the checkbox is actually a regression for users of the proprietary NVIDIA driver as that one allowed to enable/disable direct rendering.

  10. #40
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    916

    Default

    I see, this is a driver specific behaviour.
    My bad. Thanks for replying!

Posting Permissions

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