-
Notifications
You must be signed in to change notification settings - Fork 96
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
vdrift doesn't detect GL version correctly due to not setting core context #123
Comments
The GL3 renderer wasn't written against core context profile, will fail with mesa drivers. From a quick gdebugger run, the following functions used by GL3 renderer will have to be replaced by equivalent functionality: Function Name, Deprecation Reason, # of Calls, % of Calls, Deprecated at OpenGL Version, Removed at OpenGL Version |
glGetString is only used to log GPU vendor info, can be removed or made optional (for non-core context). |
With latest commits we only have: glBindTexture, glBindBuffer are false positives. glGetString(GL_EXTENSIONS) is not called by us but by SDL or GLEW. |
glGetString(GL_EXTENSION) is called by GLEW, see http://sourceforge.net/p/glew/bugs/174/?page=1 |
There is another issue I overlooked. VDrift is using client-side vertex arrays for dynamic (or non-performance critical) stuff like the GUI. They are deprecated as well from my understanding. |
https://github.com/VDrift/vdrift/tree/vertex branch replaces current vertex code with a vertex buffer system. Need to recheck what else remains to be fixed to support core profile, will have to replace glew eventually. |
I've created a core branch which forces 3.3 core profile. Seems to work on Windows. Linux, MacOS testers are welcomed. The branch depends on vertex data branch. gl2 renderer can not handle core profile yet. So this is gl3 only for now. |
Seems to select the 3.3 core profile correctly, but then stuff goes wrong:
|
Thanks Timo, that's much better :P. Windows drivers seem to be not too serious about core profile. I'll be testing a bit later under Linux with open source drivers. Will hit the same bugs hopefully. |
Linux/Mesa only needed a tiny fix: INFO: Video card information: ERROR: OpenGL error "invalid enumerant" during: bool GLWrapper::initialize():/home/nan/vdrift/src/graphics/gl3v/glwrapper.cpp:55 Even though the rendering is too dark, it works: I will try a more recent Mesa build. |
With Mesa 10.3 I am getting the same output as on Windows: http://vdrift.net/Forum/showthread.php?tid=1825 |
@Timo6 I've been looking for something akin to apitrace(OpenGL debugger) on Mac and it seems there is an OpenGL Profiler: https://developer.apple.com/library/mac/technotes/tn2178/_index.html#//apple_ref/doc/uid/DTS40007990 The idea is to try running VDrift with it and capture a call trace (Launching an application within Profiler.) to get a better idea where the driver hickups. |
The longest trace I could get (trying to collect it caused VDrift to crash after 'falling back to GL 1 or 2' in log.txt, as opposed to exiting gracefully as it does when launching normally) is here: http://pastebin.com/2GwZXFCV, and with 'Include Backtraces' ticked: http://pastebin.com/kMAxgcEL |
Thanks. It is looking quite good.The first two INVALID_ENUM and INVALID_OPERATION are non-critical, easy to fix. It seems to choke on the sixth shader depthcopy.frag Looking it up gl_FragCoord is actually deprecated, I should have double-checked it the first time. From the first look the fix would be to comment out the gl_FragColor line, as the shader should not output color anyway. |
@Timo6 I've pushed some fixes, would be cool if you cold do another trace to see how far we get. |
Sorry for the delay, been very busy and had some computer problems (so my results may not be very reliable as I've downgraded my OS among other things). With 4b442f7 and r1292 VDrift launches without any errors in the log, but the menu is running at 4fps on lowest settings. Trace (of launching, starting a race then quitting as quickly as possible to keep the trace size down!): https://gist.github.com/Timo6/484260f5b544aafa9e52, with backtraces: https://gist.github.com/Timo6/ade7ae19946a2047ec03. |
Thanks. It is a start :) What is the performance of a release build without profiling? Also I assume gl2 deferred ran on your machine before (not core profile)? What was the performance there? |
Yep, gl2 deferred on latest master (a8bd84f) gives 60fps on menus, and 40-65 (usually 60) in game on the same (lowest settings). |
Digging through the trace I see a single draw call eating most of the frame time: 1/10 sec is quite a lot time spent there. I assume it is lightaccumulate.frag (the heaviest shader), but need to compare with my traces first to be sure. The HD 3000 has 12 shader units > 100 GFLOPS I think, need to check how much time my amd card spends on this shader, assuming shader complexity is the problem here ;) |
I did some testing with a GeForce 310M ~70GFLOPS. I get 10fps with shadows, reflections maxed out at 720p. I think you should get about the same numbers at least. My current guess is that Apple glsl compiler might be having issues with the shader, hitting some fallback maybe. Need to think of some way to test it, maybe try some simplified variations of the shader in question. PS: |
I've merged core profile patches into vertex branch. Define GL3CORE to enable it. |
Been doing some more testing with 11b0990 and r1302. On lowest gl3 settings menus are up to 7fps. Will get some traces later. Max settings causes fall back to gl2/basic.conf with errors in gl3/blur.frag and gl2/deferredshadows.frag:
|
Thanks Timo. I'll look into it. shadow2D is deprecated after version 120. Why the hell does it not fail on linux/windows :P |
@Timo6 fixes for textureSize and shadow2D are in master |
With f480320 and r1306 gl3 shaders compile fine, gl2 gives:
|
And the return value of a shadow sampler is a float. :) Fix is in master. Thanks again for you tireless testing Timo. |
Nice, gl2 working great now - I can turn the settings up much higher than I ever could before 😃 |
Hey @Timo6 I've pushed a noglew branch. It replaces glew/glu dependencies with a custom loader (graphics/glcore.h and graphics/glcore.cpp). Would be awesome if you could give it a try on OSX. Seems to work quite well on Linux and Windows so far. |
gl3 is fine, gl2 falls back to basic.conf:
|
Interesting, ARB_framebuffer_object is a core feature since 3.2. I assume the driver doesn't expose it as ARB extension any more. Need to change the extension loading code to handle this, just enable extensions that are core. |
Now doesn't like floating point textures:
|
Yeah, sorry about that one, silly sopy/paste induced bug. |
Cool, that works :) |
Closing as fixed. Please open a new issue, if you still have any opengl related problems. |
Mesa's r600 driver now supports OpenGL 3.3 as indicated by glxinfo:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD REDWOOD
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
But vdrift still only detects GL version 3.0, since it does not set GL context to core:
INFO: GL Renderer: Gallium 0.4 on AMD REDWOOD
INFO: GL Vendor: X.Org
INFO: GL Version: 3.0 Mesa 10.2.0-devel
INFO: Initialized GLEW 1.9.0
ERROR: Graphics card or driver does not support required GL_VERSION_3_3
ERROR: Initialization of GL3 failed; that's OK, falling back to GL 1 or 2
INFO: Video card information:
Vendor: X.Org
Renderer: Gallium 0.4 on AMD REDWOOD
Version: 3.0 Mesa 10.2.0-devel
Maximum texture size: 16384
Maximum varying floats: 128
Using GLEW 1.9.0
When forcing GL version to 3.3 using MESA_GL_VERSION_OVERRIDE=3.3 vdrift fails to initialize OpenGL with the following error message:
ERROR: OpenGL error "invalid enumerant" during: bool GLWrapper::initialize():src/gl3v/glwrapper.cpp:67
The game hangs on startup with a black screen and spewing OpenGL error "invalid enumerant" and OpenGL error "invalid operation" messages on the console.
The text was updated successfully, but these errors were encountered: