Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: [WIN/NVidia] Context issues after context-refactoring  (Read 6035 times)

0 Members and 1 Guest are viewing this topic.

BlueCobold

  • Full Member
  • ***
  • Posts: 105
    • View Profile
[WIN/NVidia] Context issues after context-refactoring
« on: November 09, 2016, 01:45:26 pm »
I have an issue with SFML since the commit about context-refactoring.

I get an error about failed context creation and other weird stuff (like invalid handle, etc) when using the git master SFML version. It all happens since the commit about removal of internal context-usage (creating context with gl version 0.0). It only appears on my Win7 HP Notebook using an NVidia Quadro 1000M (Driver version 8.17.12.7621). Using one commit earlier does not have any issues and runs just fine. I don't have the issue on other windows machines and by trying with Tank we noticed it's not related to the compiler being used either.
code:
#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>

int main()
{
    // Errors happening in the following line (failed to deactivate, created version 0.0, failed to activate, failed to activate):
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window", 7, sf::ContextSettings(24, 8, 0, 2, 0));
    sf::Texture texture;


    // Errors also happening in the following line:
    if (!texture.loadFromFile("walls.png"))
        return EXIT_FAILURE;


    sf::Sprite sprite(texture);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        window.clear();
        window.draw(sprite);
        window.display();
    }
    return EXIT_SUCCESS;
}

Error log (the first line says: "The handle is invalid"):
(click to show/hide)

I don't think I will be the only person having this issue and I find it rather critical, especially since SFML does work with the previous commit just fine.
« Last Edit: November 10, 2016, 06:54:18 am by BlueCobold »

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML broken entirely after context-refactoring
« Reply #2 on: November 10, 2016, 02:45:07 am »
Just so that this discussion doesn't derail into another GitHub issue with an unmanageable number of comments:

First a bit of context:

Yes... the symptoms of the issue were reported even before the merge, and I think we gave enough time for the reporters to provide any sort of constructive information that would aid us in tracking down the issue. The first mention only included the information "Windows 7, runs in VM, doesn't run on the host", no mention of the GPU Vendor, driver version, or any effort what-so-ever on the part of reporter in narrowing down the search area since they are the only one with access to an environment in which the issue can be reproduced. Months went by, no other information regarding this specific issue was provided. We asked, waited, and just moved on as we would have to at some point.

Within the first week after the merge, another user reports being able to independently reproduce the issue and actually provides information that is useful to us to understand the nature of the problem. The user goes even further and suggests 2 ways to resolve the issue. Since one of them (updating a really really old driver) is in my opinion the better option for the user from a more global perspective, and I assumed that they were able to resolve the issue on their own without demanding any changes in our direction, I didn't bother to follow up on the issue, hence no comment.

3 weeks later, you also independently reproduce the same issue, with a similar environment to that of the second reporter. I would have expected that you might have took note of what they wrote since you were at some point subscribed to the PR, but I guess there might have been legitimate reasons for unsubscribing.

Now for some facts:

The reason why this only happens in certain hardware/driver configurations is due to the fact that Nvidia obviously didn't follow the API description that Microsoft provided for wglMakeCurrent.

Quote
If hglrc is NULL, the function makes the calling thread's current rendering context no longer current, and releases the device context that is used by the rendering context. In this case, hdc is ignored.

The documentation states fairly clearly that hdc is ignored when hglrc is NULL. This is not something that can/might be done or is implementation defined, it is done, which is a contract that the implementation has to fulfil. Not doing so, for whatever reasons is a breach of contract and therefore irrefutably a bug. Nvidia didn't go out of their way to fix something in their OpenGL implementation that wasn't clearly broken. The fact that it is fixed in more recent drivers shows that they acknowledge that this was a bug on their side.

I looked around the internet when the issue was clearly explained and I found the following implementations:
SDL
GLFW
Allegro
FreeGLUT

Besides SDL, none of the above libraries actually work around the bug in this outdated Nvidia driver. This would mean that you can construct cases in which those libraries would also fail to function correctly. I'm fairly certain that other similar libraries not mentioned here have also chosen the route of not trying to work around the bugs of others which have long since been fixed.

Philosophy:

Because SFML can be considered a middle-ware library, there are some things on which it has to rely on. We are not here to re-invent wheels because we can or because others have done so in the past. We simply assume that everything "below" us "just works". This includes things like the operating system, drivers and dependency libraries. That is also the ascending order in which we have influence over when it comes to fixing things "upstream". If this assumption does not hold because things happen to be broken sometimes, then the only productive way to move forward is to look for the source of the problem and solve it there. Fixing it downstream leads to more projects having to build in the same workarounds and to what end? At the end of the day, the driver maintainers at Nvidia are paid to make the smallest changes that affect the largest amount of users, why should the burden rest on those who are not paid and make the smallest change? In this case, Nvidia even delivered, and it is down to the user who is always responsible for keeping their system in a usable state by updating the things which are necessary.

I am starting to understand the reason why Microsoft made updates more or less mandatory in Windows 10: Users are simply not able to understand, too lazy or selfish when it comes to being part of the software maintenance cycle. Why put up with broken software along with millions of others when all you have to do is report it as broken and wait for it to land on your system as part of a routine update? This is also the reason why OpenGL driver support was so horrible for so long. People simply "didn't care" since DirectX was an available and not-so-crippled alternative, and of course the developers always have to cater to what the users expect and are willing to understand. Khronos made the right move with Vulkan: Push more of the support responsibility towards the game developers. For some unexplainable reason, PC gamers are more comfortable with Steam updating the same game 10 times a day than with downloading a driver update once a month themselves. Why? Because it is not as fully automated.

Software, and especially libraries, should not have to make compromises and undermine their principles just because people are lazy/ignorant/selfish. As is common these days "It's a people problem".

Comparing software among each other based on how far they are willing to go in order to "stay in the club" is also not the way to go. Just as it is not the way to go in real life. Just as in real life, judging software should be based on principles, and because every software project follows another set of principles, comparing their implementations among each other is simply ignorant. The quality of the software should be judged on whether they are able to fully fulfil their goals while staying true to their principles. Whether those principles align with those of certain users will be the deciding factor when the user considers using the library in their projects. As such, people who say/threaten things like "I won't use your library unless you do things like other library X." just show how short-sighted some people have become. There is a reason why more than one library exists, and that is because there are different groups of people with different focuses. In the end, if one values over everything else having a perfectly fitting "library" that fits their purposes 100%, nobody prevents them from just implementing it themselves, even based on forks of other open-source libraries. Threatening open-source projects leads nowhere, and people should learn to understand that.

This is not directed at anybody in particular (so please do not feel offended), it's just a trend that I have noticed creep up over the last years.

The status quo:

I've already commented in issue #1165, that more work has to be done to get the OpenGL implementation into a more stable state again. I can imagine that this might include the aforementioned workaround as well. When I have the time, I will commence work on this issue.

Just for the record: I am considering this, not out of populism or the belief that this is a justifiable way to develop software going forward, but simply due to 2 reasons. SFML's OpenGL implementation is the only rendering implementation that is currently available, and in order to guarantee a certain degree of backwards compatibility (even in the future when other renderers might be available and OpenGL becomes a fallback), we have to take into account that certain platforms are simply no longer supported and thus that a driver update might not be available for all users. This does not endorse in any way neglecting to keep drivers up to date when they are obviously available. This will remain the primary route to fix issues when it comes to troubleshooting SFML. The second reason for considering such a workaround is simply because it requires relatively low effort and affects a file that might have to be modified any way.

And finally:

Just a remark, but in my opinion, the title of this thread can be considered a bit misleading. SFML is not "broken entirely", let alone not on all platforms/hardware. This is isolated to the sfml-window module and more specifically OpenGL context management, only using a really old driver and only on Windows. Starting a thread with such a title, furthermore in the General section, can even be considered a bit as "click bait" and conflicts with the informal netiquette that can be found throughout the forum.

Also, stating that you consider this a critical issue is an acceptable opinion, however, please bear in mind that not everybody will have the time to fully understand the implications. This is specific to a bugged driver, and only affects the most recent release of SFML. If people favour stability over being at the cutting edge, we also provide all prior versions. Nobody is forced to make use of an SFML version within the first month of its release. If an older version worked 100% for them, then there is no real reason to update. Stating that a specific version of SFML is critically broken without specifying the details upon which users can decide which version they should use just creates more uncertainty than SFML currently needs.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

BlueCobold

  • Full Member
  • ***
  • Posts: 105
    • View Profile
Re: [WIN/NVidia] Context issues after context-refactoring
« Reply #3 on: November 10, 2016, 06:42:21 am »
As such, people who say/threaten things like "I won't use your library unless you do things like other library X." just show how short-sighted some people have become.
Nobody said such a thing in this topic and thus it is unrelated.
However, if there's 3 developers using SFML being affected negatively by a change, there probably are more. And those end-users will be the ones causing negative feedback. If such feedback can be prevented, it should be. I believe you will agree with that stance, even if the fault is not lying on your side according to the specification.

I can't tell you why other open source projects have a similar implementation, but I can assume that's due to everyone looking at how the other libraries did it. This does not mean that's the state of the art used by stable games. For example: If you're gooling how to handle taking pictures with the camera on Android, you will find the very same implementation on lots of forums, apps and on stackoverflow. Each of them having at least 3 (!!!) critical issues of which 2 lead to crashes on certain phones and one leads to images being displayed upside down on some devices. Just because it's commonly used, it doesn't make it a stable implementation. Each of these crashing implementations however are valid if you read the docs (which are pretty bad at this point). Since there's so many different vendor-specifics, it's still flawed and needs various tweaks and fallbacks. If you don't have them, you'll get a shitstorm from the user-base about your bad camera-handling. I just don't want that to happen yet again, especially by knowing potential issues beforehand.
« Last Edit: November 10, 2016, 06:55:23 am by BlueCobold »

ZeroZ30o

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: [WIN/NVidia] Context issues after context-refactoring
« Reply #4 on: December 05, 2016, 09:51:34 am »
Having this issue with SFML 2.4.1, with the only code being:


        sf::RenderWindow window(sf::VideoMode(800, 600), "Test");

        window.setFramerateLimit(10);

        while (window.isOpen())
        {
                window.clear(sf::Color::Black);
                window.display();
        }

        return 0;
 

Getting the same errors as bluecobold, up until the line "Failed to activate the window's context", after which there is nothing else.

Graphics card is NVidia GeForce GT 520, and according to windows, it has the latest drivers. I've searched nvidia's site for drivers and 520 has none.
« Last Edit: December 05, 2016, 09:53:31 am by ZeroZ30o »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10815
    • View Profile
    • development blog
    • Email
[WIN/NVidia] Context issues after context-refactoring
« Reply #5 on: December 05, 2016, 10:05:14 am »
What's the driver version?
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

ZeroZ30o

  • Newbie
  • *
  • Posts: 47
    • View Profile
Re: [WIN/NVidia] Context issues after context-refactoring
« Reply #6 on: December 05, 2016, 10:21:40 am »
What's the driver version?

8.17.12.8562 from 15/10/2011

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10815
    • View Profile
    • development blog
    • Email
[WIN/NVidia] Context issues after context-refactoring
« Reply #7 on: December 05, 2016, 10:31:17 am »
Is the GeForce GT 520 part of the GeForce 500 Series? If so then you can select "GeForce" and "GeForce 500 Series" over at Nvidia's driver download page to get the latest driver: http://www.nvidia.com/Download/index.aspx
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10815
    • View Profile
    • development blog
    • Email
Re: [WIN/NVidia] Context issues after context-refactoring
« Reply #8 on: December 06, 2016, 12:29:09 pm »
While the proper solution is still to update the 5+ years old driver, we've added the hack. Feel free to test it: https://github.com/SFML/SFML/pull/1172
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

BlueCobold

  • Full Member
  • ***
  • Posts: 105
    • View Profile
Re: [WIN/NVidia] Context issues after context-refactoring
« Reply #9 on: December 12, 2016, 08:51:30 am »
Test failed :( See my comment on github.

 

anything