iandol@...> wrote :
> What do you mean with "better" if you use FloatingPoint32Bit?I have a benchmarking mode (dontsync==2, flip as fast as possible), and with `FloatingPoint32Bit` depending on the stimuli I get about 100fps more than when using the EnableBits++ modes. Bits++ is also slower than Mono++ mode FWIW.-> Ok, that's expected. Mono++ needs a custom shader to execute vs. only FloatingPoint32Bit (simple fixed-function pipeline emulation shader). Color++ mode (i assume you meant that instead of Bits++) requires a shader that has to do branching (if-else statement), executing different code paths depending if it is writing color info to an even or odd column of the framebuffer. gpu's don't like that performance-wise, because computations are usually executed with the same instructions in parallel on a block of adjacent pixels in the framebuffer, e.g., 2x2 or 4x4, 8x8 or such (SIMD paradigm with masking). If all target pixels in such a block take the same branch of an if-else statement or for/while loop, or switch-case statement, then the hw has to only compute that branch. If different pixels in the block evaluate their branch-condition to different truth values, e.g., half of them want to take the if-then branch, the other ones the else branch, then the hw has to execute both branches for each pixel, then throw away the results for the "branch not (supposed to be) taken" - iow. you pay with performance loss if decisions in the shader are not taken the same way for a spatially coherent group. Or simply said, shaders don't like complex if-else statements etc., you pay for them, depending on the task at hand. Specific details vary by gpu model and vendor - and this explanation is quite a bit of an oversimplification, just to get you the idea why this happens.As you are one of the few people contributing shaders to Psychtoolbox:That's why sometimes it makes sense to write two different versions of a shader for different modes of operation, instead of one shader with an if-then-else branch. Or split up computation in multiple simple passes with less branching. In the end it is a tradeoff between squeezing out more performance vs. maintenance overhead for us having more shader variants and more need for testing different cases.If the condition for if-then-else/for-loops/while-loops etc. doesn't depend on "pixel local" or "texel local" variables (e.g., varyings or texture input in GLSL), but just on the value of uniforms, that's less of a problem, as then certain variables can be treated as constants for a large part of a render-pass -- in fact, the shader compiler may even turn such uniforms into constants and then build an instance of the shader specific to that setting, applying more optimizations. Also slowly varying input often allows larger groups of pixels to only take one common branch.> I assume you follow optimizations like ordering your loop asIn general I try to always follow that order yes, although for example I do need to get the eyelink sample before I draw the stimuli depending on the logic needed. If I check after drawing then there is a 1 flip delay if fixation was broken etc. I've profiled the simple eyelink getsample and it occupies a fraction of a millisecond. I do use an object oriented (OO) finite state machine to drive the logic of experimental tasks, and was worried that OO overhead may contribute[1]. I've profiled using No-op methods (i.e. all the OO call overhead is there but no other processing), and the state machine overhead is negligible.> Priority() scheduling etc.I use the recommended max priority == 1 for Linux, I've tried higher values just in case without much effect. I do notice priority doesn't affect the `nice` value, would changing that have any effect?-> No. The 'nice' value is only used for non-realtime scheduling, to distribute cpu time fairly (on average) across non-realtime processes. RT scheduling plays by different rules, and higher Priority() value means higher priority. The current setup file in /etc/security/limits.d/psychtoo... defines values between 0 and 50 as allowed for users in the psychtoolbox unix group. The range goes up to 99 iirc.> Obviously, if you don't need for Flip's to complete, because you use BitsPlusPlus() functions ability to send T-Lock driven strobes via the Display++, you could use non-blocking Flip via 'vblsynclevel' 1I haven't tried this yet, something to look into thanks. I am also trying to use the undocumented T-Lock2 system (the tlock can trigger I/O on the same flip rather than subsequent one), but haven't yet got it set up.>Multithreading wouldn't help either if your design would be something like a gaze-contingent display i guess. Have you profiled where time is spent?Yes, the majority of the time is spent in Screen drawing subcommands. I don't need gaze contingent drawing at the moment, but do need accurate fixation testing and communication with the eyelink and other equipment via strobed words.-> Btw. for some simple assessment of where graphics time is spent, there's the https://www.mesa3d.org/envvars.html GALLIUM_HUD environment variable (e.g., launch with export GALLIUM_HUD=blah octave). GALLIUM_HUD=help glxinfo is an easy way to list all supported options. This will draw some overlay on top of your rendering, with graphs that give an idea where processing time is spent, if the gpu is running at maximum clock etc.There are more sophisticated tools like FrameRetrace to get to the bottom of where time is spent: https://www.youtube.com/watch?v=q-5YkK3dGtI> How does Matlab become unstable with the latest Mesa drivers?This was with the padoka stable PPA a few weeks back (which was 18.1.something IIRC), I found that I would get non-reproducible MATLAB Java errors (i.e. internal errors), often occuring after a PTB run when using a Guide GUI. Unreproducibly, MATLAB would freeze and require a killall. If it had been a reproducible error I would have reported it. Perhaps things are now better with mesa 18.2?-> Ok.-marioThanks as always for your knowledge and suggestions, Ian----[1] MATLABs original OO implementation was significantly slower than functional programming, but this has changed drastically over the last few years...