Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".
This is wrong. I we really want to add hacks for specific combinations of broken drivers and applications, we should be adding exceptions for specific extensions / functions. In the specific example of bug 38480, it should be easy enough to implement the required functionality on top of the core functionality in OpenGL 1.2 if the extension is not available.
On 26 November 2015 at 08:08, Henri Verbeet hverbeet@gmail.com wrote:
This is wrong. I we really want to add hacks for specific combinations of broken drivers and applications,
And for the record, I'm not convinced we do. I think it's more productive to make sure things work with the free drivers than going out of our way to support proprietary drivers.
Henri Verbeet hverbeet@gmail.com wrote:
This is wrong. I we really want to add hacks for specific combinations of broken drivers and applications,
And for the record, I'm not convinced we do. I think it's more productive to make sure things work with the free drivers than going out of our way to support proprietary drivers.
Then you're probably working for the wrong project (and even company). Most of the targeted by Wine Windows applications are not free and not open source.
On Nov 26, 2015 1:22 AM, "Dmitry Timoshkov" dmitry@baikal.ru wrote:
Henri Verbeet hverbeet@gmail.com wrote:
This is wrong. I we really want to add hacks for specific combinations of broken drivers and applications,
And for the record, I'm not convinced we do. I think it's more productive to make sure things work with the free drivers than going out of our way to support proprietary drivers.
Then you're probably working for the wrong project (and even company).
Most
of the targeted by Wine Windows applications are not free and not open
source.
-- Dmitry.
Can we avoid personal attacks please?
On 26 November 2015 at 08:23, Austin English austinenglish@gmail.com wrote:
On Nov 26, 2015 1:22 AM, "Dmitry Timoshkov" dmitry@baikal.ru wrote:
Henri Verbeet hverbeet@gmail.com wrote:
This is wrong. I we really want to add hacks for specific combinations of broken drivers and applications,
And for the record, I'm not convinced we do. I think it's more productive to make sure things work with the free drivers than going out of our way to support proprietary drivers.
Then you're probably working for the wrong project (and even company). Most of the targeted by Wine Windows applications are not free and not open source.
-- Dmitry.
Can we avoid personal attacks please?
There's a good chance it's intended as one, but it sounds more like an attack on Wine and CodeWeavers to me. I suppose I'll let Alexandre and Jeremy reply to that if they feel the need to dignify it with a response.
Austin English austinenglish@gmail.com wrote:
This is wrong. I we really want to add hacks for specific combinations of broken drivers and applications,
And for the record, I'm not convinced we do. I think it's more productive to make sure things work with the free drivers than going out of our way to support proprietary drivers.
Then you're probably working for the wrong project (and even company).
Most
of the targeted by Wine Windows applications are not free and not open
source.
-- Dmitry.
Can we avoid personal attacks please?
Is calling a thing ridiculous called a "personal attack" these days? When one of core d3d developers (who happens to work for CodeWeavers) starts to advertise free drivers in preference to proprietary ones, while main target and revenue source for CodeWeavers currently are MacOSX users, this at least sounds weird and strange, especially taking into account amount of Mac/Apple specific quirks in the wined3d code (including supported extenstions tweaks). Or probably 'make test' in Wine no longer crashes and has no failures with nouveau drivers? Or probably now it's nouveau who privdes bleeding edge hardware and drivers for linux? Not even mentioning that Henri decided to completely ignore questions in the patch.
Am I missing something?
On 26 November 2015 at 10:35, Dmitry Timoshkov dmitry@baikal.ru wrote:
Am I missing something?
Nuance, subtlety, and my respect, among others.
On 26.11.2015 08:14, Henri Verbeet wrote:
On 26 November 2015 at 08:08, Henri Verbeet hverbeet@gmail.com wrote:
This is wrong. I we really want to add hacks for specific combinations of broken drivers and applications,
And for the record, I'm not convinced we do. I think it's more productive to make sure things work with the free drivers than going out of our way to support proprietary drivers.
I don't think Wine can really ignore compatibility with proprietary drivers, which in fact are preferred by a lot of people on Linux. Of course there might also be other solutions, but its not clear to me why you call this solution "wrong", when it works exactly the same way on Windows. You'll find plenty of examples where the Windows driver returns a non-NULL pointer, although the corresponding extension is not listed / supported. Its clearly way more effort to fix all this manually with compatibility code, and I do not see any real benefit. Can you explain why you think its better to keep this code, despite the fact that it causes regressions and has no real advantage? Or is there any (a specific app or game for which it was added)?
Best regards, Sebastian
On 26 November 2015 at 12:45, Sebastian Lackner sebastian@fds-team.de wrote:
I don't think Wine can really ignore compatibility with proprietary drivers, which in fact are preferred by a lot of people on Linux.
Sure, and I'm not saying that, at least in case of the NVIDIA ones. But there's a lot of space between completely ignoring those drivers or breaking them on purpose and going out of our way to make sure everything works perfectly with the proprietary drivers at the cost of more complicated code (granted, not a real issue in this specific case), or compatibility with other drivers.
There's also such a thing as fixing problems in the correct place, and I'm sure Nouveau would be in much better shape if all the effort spent on writing workarounds for bugs in the proprietary drivers had been spent on improving the free drivers instead.
Essentially, I think the number of affected users doesn't outweigh doing the correct thing in this case.
Of course there might also be other solutions, but its not clear to me why you call this solution "wrong", when it works exactly the same way on Windows. You'll find plenty of examples where the Windows driver returns a non-NULL pointer, although the corresponding extension is not listed / supported.
Not exactly. In the cases where the Windows driver returns a non-NULL pointer, calling that pointer will usually do something more or less reasonable. I.e., there may be functions that are available for which no corresponding extension is advertised in the extension string, but you won't get back a pointer for functions that aren't implemented at all. Checking for a non-NULL pointer from wglGetProcAddress() is a valid way to check if a function is available on WGL.
With GLX that's not the case, and calling glXGetProcAddress() with a random string will return a non-NULL pointer, that in the (arguably) best case just does nothing when you call it. The only valid way to check if an extension is available on GLX is to check the extension string. Calling glXGetProcAddress("glCopyTexSubImage3DEXT") may return a valid pointer on one driver, but an invalid one on another, with no way to distinguish between the two until after you've called them.
Henri Verbeet hverbeet@gmail.com writes:
Essentially, I think the number of affected users doesn't outweigh doing the correct thing in this case.
Correct me if I'm wrong, but isn't this simply a matter of returning glCopyTexSubImage3D if glCopyTexSubImage3DEXT is missing? That seems a better solution than relying on quirks of the Nvidia driver.
Could someone please give this a try so that we can solve this regression for 1.8?
On 27 November 2015 at 06:21, Alexandre Julliard julliard@winehq.org wrote:
Essentially, I think the number of affected users doesn't outweigh doing the correct thing in this case.
Correct me if I'm wrong, but isn't this simply a matter of returning glCopyTexSubImage3D if glCopyTexSubImage3DEXT is missing? That seems a better solution than relying on quirks of the Nvidia driver.
I think so, yeah.
On 27.11.2015 06:21, Alexandre Julliard wrote:
Henri Verbeet hverbeet@gmail.com writes:
Essentially, I think the number of affected users doesn't outweigh doing the correct thing in this case.
Correct me if I'm wrong, but isn't this simply a matter of returning glCopyTexSubImage3D if glCopyTexSubImage3DEXT is missing? That seems a better solution than relying on quirks of the Nvidia driver.
Could someone please give this a try so that we can solve this regression for 1.8?
@Henri: Thanks for the explanation about the difference of wglGetProcAddress and glXGetProcAddress, I wasn't aware that the Windows version works more reliable, which explains why you would like to keep this part. Do you see any other chance to implement a more general detection which functions are available, than to rely on the extension string? Analyzing thunk wrappers, or doing a test call with exception handler would probably work, but sounds a bit too ugly. :/
@Alexandre: Just to make sure I tested it in practice, and it indeed solves the bug. It would be acceptable but 1.8, but wouldn't solve https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that its technically not a Wine bug, but it could still be solved by being less strict with extension filtering. Both MESA and NVIDIA return valid valid function pointers in this case.
Regards, Sebastian
Sebastian Lackner sebastian@fds-team.de writes:
@Alexandre: Just to make sure I tested it in practice, and it indeed solves the bug. It would be acceptable but 1.8, but wouldn't solve https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that its technically not a Wine bug, but it could still be solved by being less strict with extension filtering. Both MESA and NVIDIA return valid valid function pointers in this case.
Actually I would argue that it is a Wine bug. If you can get a valid function on Windows even when the extension is missing, you should get one on Wine. Conversely, if you get a NULL pointer on Windows for a missing function, you should get NULL on Wine too.
This means that we have a responsibility to properly remap functions and extensions between the Windows and the Unix side. We can't simply forward to the Unix driver and hope that it happens to follow the Windows semantics.
2015-11-27 0:54 GMT-07:00 Alexandre Julliard julliard@winehq.org:
Sebastian Lackner sebastian@fds-team.de writes:
@Alexandre: Just to make sure I tested it in practice, and it indeed solves the bug. It would be acceptable but 1.8, but wouldn't solve https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that its technically not a Wine bug, but it could still be solved by being less strict with extension filtering. Both MESA and NVIDIA return valid valid function pointers in this case.
Actually I would argue that it is a Wine bug. If you can get a valid function on Windows even when the extension is missing, you should get one on Wine. Conversely, if you get a NULL pointer on Windows for a missing function, you should get NULL on Wine too.
This means that we have a responsibility to properly remap functions and extensions between the Windows and the Unix side. We can't simply forward to the Unix driver and hope that it happens to follow the Windows semantics.
After giving it some thought, I think this could work. As long as we're sure that suffixed functions behave identically to their unsuffixed counterparts, we should be able to return a function pointer to a suffixed function even though a unsuffixed function was requested (as long as the suffixed function is advertised in the extension list).
This would match both: - Windows returning function pointers for unsuffixed functions even though the rest of the OpenGL version is not available - GLX providing no guarantee that calling a function not defined in the GL version or extension list won't crash the program, even though an unsuffixed equivalent could work fine
And it would cleanly resolve bugs 38480 and 39563.
-Alex
2015-11-27 12:15 GMT-07:00 Alex Henrie alexhenrie24@gmail.com:
2015-11-27 0:54 GMT-07:00 Alexandre Julliard julliard@winehq.org:
Sebastian Lackner sebastian@fds-team.de writes:
@Alexandre: Just to make sure I tested it in practice, and it indeed solves the bug. It would be acceptable but 1.8, but wouldn't solve https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that its technically not a Wine bug, but it could still be solved by being less strict with extension filtering. Both MESA and NVIDIA return valid valid function pointers in this case.
Actually I would argue that it is a Wine bug. If you can get a valid function on Windows even when the extension is missing, you should get one on Wine. Conversely, if you get a NULL pointer on Windows for a missing function, you should get NULL on Wine too.
This means that we have a responsibility to properly remap functions and extensions between the Windows and the Unix side. We can't simply forward to the Unix driver and hope that it happens to follow the Windows semantics.
After giving it some thought, I think this could work. As long as we're sure that suffixed functions behave identically to their unsuffixed counterparts, we should be able to return a function pointer to a suffixed function even though a unsuffixed function was requested (as long as the suffixed function is advertised in the extension list).
This would match both:
- Windows returning function pointers for unsuffixed functions even
though the rest of the OpenGL version is not available
- GLX providing no guarantee that calling a function not defined in
the GL version or extension list won't crash the program, even though an unsuffixed equivalent could work fine
And it would cleanly resolve bugs 38480 and 39563.
Sorry, I meant to say "even though a suffixed equivalent could work fine".
-Alex
2015-11-27 12:15 GMT-07:00 Alex Henrie alexhenrie24@gmail.com:
And it would cleanly resolve bugs 38480 and 39563.
Correction: Substituting suffixed function pointers for unsuffixed ones should fix bug 39563, but it would not fix 38480. Since bug 39563 probably doesn't affect the proprietary driver and there is an easy workaround for the open source driver, it's probably not worthwhile to pursue this solution.
So, unless more compelling evidence is presented, I'm with Henri: I'd prefer to refocus our efforts on improving the Nouveau driver's performance or petitioning Nvidia to finish implementing the extensions that they partially support. Just reverting the patch is not a palatable solution.
-Alex
On 27 November 2015 at 08:18, Sebastian Lackner sebastian@fds-team.de wrote:
@Henri: Thanks for the explanation about the difference of wglGetProcAddress and glXGetProcAddress, I wasn't aware that the Windows version works more reliable, which explains why you would like to keep this part. Do you see any other chance to implement a more general detection which functions are available, than to rely on the extension string? Analyzing thunk wrappers, or doing a test call with exception handler would probably work, but sounds a bit too ugly. :/
Nothing that's reliable. E.g. that a function doesn't crash when you call it doesn't mean it will actually work. And in the general case you would somehow need to construct a set of valid parameters.
-
Alex Henrie -
Alexandre Julliard -
Austin English -
Dmitry Timoshkov -
Henri Verbeet -
Sebastian Lackner