Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2022-08-08 10:36:39



Reply to topic  [ 29 posts ]  Go to page Previous  1, 2, 3
Experimental viewer v1.29.0 feedback thread 
Author Message

Joined: 2016-06-19 21:33:37
Posts: 276
Location: San Francisco bay area, CA, USA
Reply with quote
Henri Beauchamp wrote:
I do not see either how the changes I brought to the GL image worker could have improved things (they are mostly related to video mode changes and shutdown procedures)... On the other hand, it was likely a race condition that occurred in specific conditions, and simple timing changes (due to code changes/optimizations) could prevent it to happen...
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
Profile

Joined: 2011-10-07 10:39:20
Posts: 154
Reply with quote
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.

Code:
2022-04-27 21:50:46Z INFO: display_stats: FPS: 34.04
2022-04-27 21:50:47Z INFO: LLAppearanceMgr::requestServerAppearanceUpdate: Sending server-side rebake request with COF version: 297020 (last requested version: -1 - last received update version: 297009)
2022-04-27 21:50:48Z INFO: LLAppearanceMgr::serverAppearanceUpdateSuccess: Request OK.
2022-04-27 21:51:01Z WARNING: LLTextureFetchWorker::onCompleted: Texture: 29d5412f-9412-9905-b2bf-54daa179327e CURL GET FAILED, status: Http_404 - reason: Not Found
2022-04-27 21:51:01Z WARNING: LLTextureFetchWorker::doWork: Texture 29d5412f-9412-9905-b2bf-54daa179327e: failed harder
2022-04-27 21:51:01Z WARNING: LLViewerFetchedTexture::updateFetch: No data received for image 29d5412f-9412-9905-b2bf-54daa179327e, setting as missing. decode_priority = 2.30101e+06 - mRawDiscardLevel = 32767 - current_discard = -1
2022-04-27 21:51:01Z WARNING: LLViewerFetchedTexture::setIsMissingAsset: 29d5412f-9412-9905-b2bf-54daa179327e: Marking image as missing
2022-04-27 21:51:09Z INFO: LLViewerMediaImpl::navigateTo: NOT LOADING media id = 5748decc-f629-461c-9a36-a35a221fe21f - url =  - mime_type = text/html
2022-04-27 21:51:09Z INFO: LLViewerMedia::getCurrentUserAgent: User agent: SecondLife/1.29.0.2 (Cool VL Viewer; dark skin)
2022-04-27 21:51:09Z INFO: LLProcessLauncher::launch: Executable: C:\devel\sl\cool\linden\viewer-win64-release\SLPlugin.exe arguments: "C:\devel\sl\cool\linden\viewer-win64-release\SLPlugin.exe" 27005
2022-04-27 21:51:09Z INFO: LLPluginMessagePipe::pumpInput: Got EOF from plugin socket.
2022-04-27 21:51:09Z INFO: LLPluginProcessParent::receiveMessage: plugin version string: Dullahan 1.12.3/CEF 91.1.21/Chromium 91.0.4472.114
2022-04-27 21:51:09Z INFO: LLPluginProcessParent::receiveMessage: Message class: base -> version: 1.0
2022-04-27 21:51:09Z INFO: LLPluginProcessParent::receiveMessage: Message class: media -> version: 1.0
2022-04-27 21:51:09Z INFO: LLPluginProcessParent::receiveMessage: Message class: media_browser -> version: 1.0
2022-04-27 21:51:09Z INFO: LLViewerMediaImpl::updateMediaImage: Initializing media placeholder with  movie image id: 5748decc-f629-461c-9a36-a35a221fe21f
2022-04-27 21:51:09Z c:\devel\sl\cool\linden\indra\newview\llviewertexture.cpp(3678) : error
2022-04-27 21:51:09Z ERROR: LLViewerMediaTexture::addFace: The face does not have a valid texture before media texture.


Code:
>   CoolVLViewer.exe!LLViewerMediaTexture::addFace(unsigned int,class LLFace *)   C++
    CoolVLViewer.exe!LLFace::setTexture(unsigned int,class LLViewerTexture *)   C++
    CoolVLViewer.exe!LLFace::switchTexture(unsigned int,class LLViewerTexture *)   C++
    CoolVLViewer.exe!LLViewerMediaTexture::setPlaying(bool)   C++
    CoolVLViewer.exe!LLViewerMediaImpl::update(void)   C++
    CoolVLViewer.exe!LLViewerMedia::updateMedia(void *)   C++
    CoolVLViewer.exe!LLAppViewer::idle(bool)   C++
    CoolVLViewer.exe!LLAppViewer::frame(class LLEventPump &)   C++
    CoolVLViewer.exe!LLAppViewer::mainLoop(void)   C++
    CoolVLViewer.exe!WinMain()   C++


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...


Attachments:
CoolVLViewer_24780.7z [30.16 KiB]
Downloaded 13 times
2022-04-27 22:09:29
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
kathrine wrote:
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.
Yep, with the threaded image creation, the llerrs responsible for this "voluntary crash" is no more valid. I will remove it for next release...

Quote:
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...
Indeed... I otherwise do not see why permissions would be wrong just for *.dsf files...


2022-04-27 22:24:39
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 276
Location: San Francisco bay area, CA, USA
Reply with quote
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
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
ZaneZimer wrote:
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.
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).

Quote:
My basic question, is there a trade off of frame frame for faster texture loading and those worker threads being present?
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
Profile WWW

Joined: 2016-06-19 21:33:37
Posts: 276
Location: San Francisco bay area, CA, USA
Reply with quote
Henri Beauchamp wrote:
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).
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
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
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
Profile WWW

Joined: 2022-04-13 22:13:27
Posts: 4
Reply with quote
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
Profile

Joined: 2009-03-17 18:42:51
Posts: 4956
Reply with quote
GismoZ wrote:
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.
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)...

Quote:
Question: where can i look up how many GL / Decoding threads being (really) generated?
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).

Quote:
P.S: really awesome work you did, I got 50 -100% (in some cases) fps improvement
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
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 29 posts ]  Go to page Previous  1, 2, 3

Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.