Experimental viewer v1.29.0 feedback thread
| Author |
Message |
|
ZaneZimer
Joined: 2016-06-19 21:33:37
Posts: 342
Location: Columbus area, OH, USA
|
Right. I wasn't implying anything was specifically changed to mitigate the issue because I also notice the mini-map terrain textures seem to appear much more often now as well. Both things 'feel' like some sort of race condition that I'm now 'on the other side' of. I'm quite happy with the performance of the experimental releases. I'm using it as my 'full time' viewer.
|
| 2022-04-23 18:25:00 |
|
|
|
kathrine
Joined: 2011-10-07 10:39:20
Posts: 181
|
Saw one crash on assert, but still on 1.29.0.2. Will try to build a 1.29.0.3 with debug info to see if it happens again. Teleported to a new region, walked for maybe half a minute before the assert/abort came up. No readable minidump as this was a self built release build. I also noticed a lot of Access Denied (errno 13) errors from the FMOD code, might be the Virus Scanner. I should add some exceptions...
|
| 2022-04-27 22:09:29 |
|
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51
Posts: 5545
|
Yep, with the threaded image creation, the llerrs responsible for this "voluntary crash" is no more valid. I will remove it for next release... Indeed... I otherwise do not see why permissions would be wrong just for *.dsf files...
|
| 2022-04-27 22:24:39 |
|
|
|
ZaneZimer
Joined: 2016-06-19 21:33:37
Posts: 342
Location: Columbus area, OH, USA
|
Perhaps I am misunderstanding the purpose of the worker threads. I have been doing a bit of testing this morning and experience a noticeable drop in frame rate if I enable GLWorkerThreads, either in auto (-1) or a non-zero value. I have tried 1, 2 and 4. On my home parcel, facing the same heading and giving some time for things to load, etc, I can get about 70-75 fps with the workers disabled. If I enable, either in auto or some non-zero, the frame rate tops out about 60 fps, but mostly hovers in the mid-50s.
My basic question, is there a trade off of frame frame for faster texture loading and those worker threads being present?
|
| 2022-05-01 14:06:03 |
|
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51
Posts: 5545
|
 Your question is totally legitimate, and yes, there is a cost at the GL worker thread... Each frame, the viewer main thread needs to run the "callbacks" to the worker thread (so to recover the newly created GL images). It would be fine and dandy as long as it won't involve taking time when no callback is pending, but sadly, this is not the case: in order to query for the callbacks, the main thread needs to take a lock on the worker queue, and this costs time, especially since the worker threads are fast spinning and themselves compete for that same lock, which can result, when the lock is taken, in the rescheduling of the main thread by the OS, meaning it can be paused for several ms whenever the lock is already taken by a thread ! I am currently optimizing this part of the code (by checking for the queue approximate size, i.e. using the size of the container without taking a lock, meaning it could be slightly wrong/off by one or two), before actually running the worker queue on the main thread for callbacks... Stay tuned (the "fix" will likely be ready for next release). Yes, there will always be a trade-off anyway (between fps rate stability/smoothness during rezzing and peak fps rate once everything is rezzed), because, beside the issue I exposed above (which makes for the largest fps drop seen), there is anyway always a cost in running more threads: the OS scheduler needs to perform more work, and the CPU core running the main thread could see the other threads affected to it as well (and at each thread context switch that CPU core's instruction cache will be largely invalidated, the data cache will have to be shared between threads, etc): your best bet is to use the thread affinity feature of the Cool VL Viewer ("MainThreadCPUAffinity") to reserve one full (Windows) or two full (Linux) CPU cores to the main thread; the worker threads (of all kinds, not just the GL ones) will be forbidden to use these reserved core(s).
|
| 2022-05-01 17:13:15 |
|
|
|
ZaneZimer
Joined: 2016-06-19 21:33:37
Posts: 342
Location: Columbus area, OH, USA
|
Nice. I thought perhaps, it was just an expected trade off and perhaps I had missed (though couldn't find) explicit mention of such a caveat. As always, I look forward to giving the improvement a try.
|
| 2022-05-01 17:33:16 |
|
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51
Posts: 5545
|
Please note that v1.29.0 is nearing the promotion to the next stable branch; if you did not yet test it, do it now and report any issue you would encounter when compared with v1.28.2. I am especially interested in knowing if: - You had to enable the "GLWorkerUseFence" debug setting to avoid flashing/bogus textures.
- You had to disable the "GLWorkerUseForBumpMaps" debug setting to avoid bogus bump map textures.
- You could not use the GL thread(s) with a specific GPU/driver/OS configuration.
|
| 2022-05-07 18:10:28 |
|
|
|
GismoZ
Joined: 2022-04-13 22:13:27
Posts: 8
|
I didn't need any of these and worked just fine with Nvidia graphics. Off topic: just realized heavy populated places (~80 ppl) higher CPU usage dropping fps very low a short time (~10 secs), especially when moving cam.
Question: where can i look up how many GL / Decoding threads being (really) generated?
P.S: really awesome work you did, I got 50 -100% (in some cases) fps improvement
|
| 2022-05-09 22:50:07 |
|
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51
Posts: 5545
|
Watch out for excessive texture memory setting: in the Texture console, whenever the "Bound" GL memory overshoots 4GB, I noticed dramatic FPS drops with NVIDIA cards (this might be an issue with how VRAM is addressed in them)... This may transitorily happen in texture-heavy environments (such as a place with a lot of people and with ALM on: materials can really eat up your texture memory quickly), and usually when turning the camera around. The GL bound memory limit is set to a (large) fraction of the Texture memory, but this is a soft limit (which may be overshot, the time for the texture fetcher to readjust the texture LODs). If you see such issues, reduce the "Texture memory" setting in the "GPU/GL features" sub-tab of the Graphics preferences: 2.5GB of texture memory (which should set the GL bound memory soft limit to 2GB) should be plenty enough anyway (LL's viewer limits the texture memory to only 512MB, which is too low)... Either in the corresponding spinners (if you set anything else than the "auto" setting), or in the viewer log (a full report about the number of threads started is given there, as well as the work done by each thread on viewer shutdown). Thanks. Just a one liner though... And I wish I would have found it sooner (all these years with that silly and detrimental glFinish()...).
|
| 2022-05-10 00:17:58 |
|
|
Who is online |
Users browsing this forum: No registered users and 25 guests |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
|
|
