primus
primus copied to clipboard
amonakov
Multisampling AA limited by iGPU capabilities
Couldn't get Freespace 2 working unless I turned down the AA to 4x. It will run, but flicker constantly. Optirun can handle 8x and 16x (ignoring framerate).
FXAA seems to work fine.
Unfortunately, SDL uses glXChooseVisual to setup multi-sampling AA. Unlike GLXFBConfigs, X Visuals can be used outside of the GLX implementation (to actually create the window via Xlib), and therefore primus returns X Visuals that correspond to the primary X display. This means that multisampling is limited to what displaying libGL (Mesa) supports.
Sorry, but the core issue cannot be reasonably fixed in primus. A partial workaround might be possible for applications that use glXChooseFBConfig. Additionally, in future a global multisampling override variable might be added, similar to VGL_SAMPLES.
It's surprising that you get flickering only with MSAA. Are you running under compositing? Have you tried prepending PRIMUS_SYNC=1 (or =2)?
PRIMUS_SYNC=2 seems get rid of the flickering with MSAA. Framerate is halved though.
And yes, I'm running gnome-shell.
@amonakov would it be possible to return the currently max mesa MSAA support in primus instead the dedicated one? I think that there is a OpenGL function for that, but I'm not sure here.
@karolherbst, I don't see practical value in that. Suppose max Mesa MSAA is 4x and max nVidia MSAA is 16x. If the application asks for 2x or 4x MSAA, it works, and MSAA is exactly what the application asked for. If it asks for 8x or 16x, it does not, which is not fixable as I explained. If it asks for 32x, it does not, which is reasonable because nVidia does not support that.
Your suggestion would cause the application to "work" when it asked for 8x or 16x MSAA, but the actual MSAA value would be 4x. It does not make sense to implement, because the application can ask for 4x MSAA in the first place.
I thought, that there is a method like "glgetMaxMSAALevel" or something like that. If there isn't such a function, then my idea is very senseless
Btw, no luck with Cinnamon 2D. Still flickers.
Will Primus be able to do flicker-free MSAA 4x eventually with that added variable?
Probably yes. I wonder what's causing flickering now though (without compositing) — possibly a bug in primus or Mesa.
Flickering was present with stock 12.10 graphics stack as well as xorg-edgers (pretty much git of everything).
Kernels tested were 3.5 and 3.7-rc4.
What exactly do you call "flickering" ?
I tried many games tonight with Ubuntu 12.10, basic, up to date Bumblebee install, with Primus PPA. Hardware : Intel i7 and nvidia geforce 540M. Unity/Compiz is set to un-redirect fullscreen windows, so the the performance is better than with default Unity/Compiz settings. Still not on par with Gnome-shell though.
With the default configuration (running things with primusrun, no flags) in many cases, that "flickering" is a wrong frame ordering. Frames are displayed with no specific order, and it's like watching a really fast shuffled slideshow.
It is most noticeable in Deus Ex : Human Revolution, in cutscenes. It happens "in game" in Source games (I tried Portal 2 and HL2 Episode 2). It is less noticeable in Unreal Engine Games (Bioshock and Dead Space) but you can notice there is something wrong by moving the view very fast : some frames appear like flashes, in the wrong place.
The issue is fixed in cutscenes with PRIMUS_SYNC=1. But it gets worse "in game", with the frame ordering completely shuffled. The issue is fixed (at the cost of performance, but with less input lag) by setting PRIMUS_SYNC=2.
I hope this is useful data.
Could this flickering issue (actually "wrong frame ordering") be related to process priority, or threading model (i really know nothing to how primus may interact with Wine or other games so i may be completely wrong with this guess) ?
@reinis Looks like this bugreport might benefit from your input.
I have never seen anything like this. Internally, primus uses locking to ensure that frames are read back and displayed in-order, regardless of threads' priorities. There have been reports linking it to the window manager's behavior or Intel-side OpenGL implementation, but nothing is known for sureee yet.
I have also problem with Nexuiz and antialiasing. Look at this: http://youtu.be/ktFEjIokbKM
When I run game with anti-aliasing enabled, screen flickers constantly. Then, if I turn off AA and enable it again, everything runs properly.
I don't have this issue with virtualgl.
Interesting. Thanks for the video. It looks like the Kerbal Space Program "incomplete frame" bug (#92). However it would be best if you opened a separate bug — this one is about MSAA level limitation.