Cool VL Viewer forum http://sldev.free.fr/forum/ |
|
Experimental viewer v1.29.0 feedback thread http://sldev.free.fr/forum/viewtopic.php?f=5&t=2268 |
Page 3 of 3 |
Author: | ZaneZimer [ 2022-04-23 18:25:00 ] | |||||||||
Post subject: | Re: Experimental viewer v1.29.0 feedback thread | |||||||||
|
Author: | kathrine [ 2022-04-27 22:09:29 ] | ||||||||||||||||||||
Post subject: | Re: Experimental viewer v1.29.0 feedback thread | ||||||||||||||||||||
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...
|
Author: | Henri Beauchamp [ 2022-04-27 22:24:39 ] | ||||||||||||||||||
Post subject: | Re: Experimental viewer v1.29.0 feedback thread | ||||||||||||||||||
|
Author: | ZaneZimer [ 2022-05-01 14:06:03 ] |
Post subject: | 1.29.0 and GLWorkerThreads |
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? |
Author: | Henri Beauchamp [ 2022-05-01 17:13:15 ] | ||||||||||||||||||
Post subject: | Re: 1.29.0 and GLWorkerThreads | ||||||||||||||||||
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).
|
Author: | ZaneZimer [ 2022-05-01 17:33:16 ] | |||||||||
Post subject: | Re: 1.29.0 and GLWorkerThreads | |||||||||
|
Author: | Henri Beauchamp [ 2022-05-07 18:10:28 ] |
Post subject: | Re: Experimental viewer v1.29.0 feedback thread |
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:
|
Author: | GismoZ [ 2022-05-09 22:50:07 ] |
Post subject: | Re: Experimental viewer v1.29.0 feedback thread |
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 |
Author: | Henri Beauchamp [ 2022-05-10 00:17:58 ] | |||||||||||||||||||||||||||
Post subject: | Re: Experimental viewer v1.29.0 feedback thread | |||||||||||||||||||||||||||
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)...
|
Page 3 of 3 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |