Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix crashing on startup with AMD GPUs #949

Merged
merged 2 commits into from
Mar 13, 2024
Merged

Conversation

acolwell
Copy link
Collaborator

@acolwell acolwell commented Mar 6, 2024

Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. Additionally, make sure you've done all of these things:

PR Description

What type of PR is this? (Check one of the boxes below)

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Improvement (non-breaking change which does not add functionality nor fixes a bug but improves Natron in some way)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • My change requires a change to the documentation
    • I have updated the documentation accordingly

What does this pull request do?

This change fixes the crashes on startup when running Natron on Windows with a AMD GPU. The fix primarily just moves GL context creation earlier in the AMD logic so that we have an active context when the AMD extension functions are called.

Have you tested your changes (if applicable)? If so, how?

Yes. I tested this on a machine with an AMD GPU and verified that the old code crashed, and this new logic does not. I also verified that the code still works on a Windows machine with an NVIDIA GPU and a different machine with an Intel integrated GPU. All of these appear to work fine.

Futher details of this pull request

While it seems bad form that the AMD driver crashes the process when there was a null context, I do believe Natron's code was incorrect. Functions returned from wglGetProcAddress() are technically specific to the context that is current when the method is called. Different contexts can return different functions according to the Windows docs, so calling one of these functions without an active context seems to be in undefine behavior territory. I believe that the caching of extension pointers in the OSGLContext_wgl_data struct and reusing them for all contexts is in undefined behavior territory as well, but it seems to work. I've left fixing that out of this PR for now since the focus of this change is simply to fix the crashes.

acolwell added 2 commits March 5, 2024 15:30
…xt_win.

This change does not modify behavior. It just introduces a helper class
to make it easier to manage the creation of temporary contexts, making
them current, and then cleaning them up when no longer needed.
This change makes sure there is an active context when
GetGPUInfoAMD() is called. While it is not explicitly stated in
https://www.opengl.org/registry/specs/AMD/wgl_gpu_association.txt
that a GL context needs to be current, it is somewhat implied by
the fact that these extension methods are fetched via
wglGetProcAddress(). According to the Windows docs, function
addresses are specific to a context so using them without an
active context seems to be undefined territory.
@rodlie
Copy link
Contributor

rodlie commented Mar 6, 2024

Awesome 👍 (not tested)

I have one or two Radeon GPUs somewhere I can test.

Copy link
Member

@devernay devernay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't test, but author has tested it and it seems legit.
LGTM

@acolwell acolwell merged commit 9679f57 into NatronGitHub:RB-2.5 Mar 13, 2024
3 checks passed
@acolwell acolwell deleted the fix_amd branch March 13, 2024 05:54
@acolwell acolwell mentioned this pull request Mar 13, 2024
10 tasks
@acolwell acolwell mentioned this pull request Nov 7, 2024
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants