AMD, please give us EGL or decent direct rendering.

[bridgman]

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.

[Dandel]

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.

[bridgman]

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

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 ?

[Dandel]

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)

[bridgman]

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.

[mgraesslin]

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.

[markg85]

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

[entropy]

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.

[mgraesslin]

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.

[entropy]

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