We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1615

Summary: SDL can't set video mode on Linux with MSAA more than 4x
Product: SDL Reporter: Michael Kurinnoy <viewizard>
Component: videoAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: icculus, matthias.bentrup
Version: 1.2.15   
Hardware: x86_64   
OS: Linux   

Description Michael Kurinnoy 2012-10-05 06:53:17 UTC 
Just a simple code,

glGetIntegerv(GL_MAX_SAMPLES_EXT, &maxSamples);

show me 16 as max samples. 

glGetIntegerv( GL_MAX_MULTISAMPLE_COVERAGE_MODES_NV, &coverageSampleConfigs);

show me 7 configs available for AA, and with

glGetIntegerv( GL_MULTISAMPLE_COVERAGE_MODES_NV, coverageConfigs);

I can see all of them, and MSAA really have 16x max on my video card. But than, when I use 8 or 16 samples with

SDL_GL_SetAttribute(SDL_GL_MULTISAMPLEBUFFERS, 1);
SDL_GL_SetAttribute(SDL_GL_MULTISAMPLESAMPLES, ...);

and trying SDL_SetVideoMode... no matter what window size/flags are used, all the time SDL can't set video mode and create window. 2 or 4 MSAA works just fine, but not 8 or 16. I can only override and set 8 or 16 MSAA via Nvidia Settings utility.


Same PC with same hardware, in Windows 7 all works like a charm, but not in Linux. On both I use the same version 1.2.15
Comment 1 Michael Kurinnoy 2012-10-06 12:02:24 UTC 
Forgot to say, SDL error is "Couldn't find matching GLX visual"
Comment 2 Michael Kurinnoy 2012-10-12 05:25:22 UTC 
I look around a little more, looks like this bug connected to glXChooseVisual implementation in nvidia drivers, but not to libSDL directly. I really see nothing in SDL_x11gl.c what could be wrong with initialization.

Just tested FBO with GL_EXT_framebuffer_multisample extension - all works like a charm on 8 and 16 samples.
Comment 3 Matthias Bentrup 2013-11-11 16:15:26 UTC 
I guess this behaviour is caused by setting SDL_GL_ACCELERATED_VISUAL to 1.

Unfortunately NVidia drivers set the "non-conformant" caveat in all MSAA visuals, and SDL requests a visual with no caveats when an accelerated visual is required (to disallow contexts with the "slow" caveat).

If you set SDL_GL_ACCELERATED_VISUAL to -1, the driver can return a MSAA visual.
Comment 4 Michael Kurinnoy 2013-11-12 11:40:13 UTC 
I checked this issue now on Linux with 325.15 nvidia driver.
Looks like, this issue was fixed by nvidia in drivers. I can't reproduce this issue now on same hardware with same 1.2.15 libsdl version and with the same test code, what I used year ago.
Comment 5 Sam Lantinga 2013-11-15 06:13:16 UTC 
It sounds like this is fixed by NVIDIA.
Comment 6 Ryan C. Gordon 2013-11-15 21:25:16 UTC 
(In reply to Sam Lantinga from comment #5)
> It sounds like this is fixed by NVIDIA.

I'm wondering if we should just ignore the SDL_GL_ACCELERATED_VISUAL flag for SDL 2.1 (or...2.0.2?). That thing has caused problems like this before, and...who doesn't want an accelerated visual? It seems like a silly thing to make the app specify.

--ryan.
Comment 7 Sam Lantinga 2013-11-16 04:12:07 UTC 
Not a bad idea... I think at this point it's only used to prevent an accelerated visual, but that's silly too. :)