Jump to content

Aishagain

Resident
  • Posts

    1,448
  • Joined

  • Last visited

Posts posted by Aishagain

  1. @Henri Beauchamp

    thanks, but your answer has two "firsts" and I am unclear as to which I am likely to have on my bios.

    I assume the "above 4G decoding"?

    My PC is over 3 years old so I assume it won't have the other setting.

    The effect I am seeing almost certainly involves incidents of swapping into system RAM.

    Disabling the dynamic texture memory setting results in quite a lot of texture thrashing but does eliminate the stutters and freezes ( I have tested it during making checks for the FS Jira, FIRE-32868, I raised) but I guess I'll just have to live with that.

  2. Well, I haven't the foggiest notion of the details of what you say @Henri Beauchamp, but that phenomenon does occur when texture VRAM use exceeds 4GB, and at a couple of dance clubs I can fill the texture memory with a 64m dd in less than 30 minutes.  Camming around then definitely provokes the long stutter/freeze effects.

    Having said all that, what can I do about it? My GPU has 6GB VRAM and the dynamic texture memory setting of FS allows me to use 4GB, should I reduce that and if I did won't that promote texture thrashing?

  3. This issue of high RAM use in Firestorm is something I am currently trying to assess.  I sometimes encouter FS using in excess of 8GB RAM, and while my GPU (NVidia GTX1660Ti) has 6GB VRAM, I find that Firestorm not only uses a LOT more RAM in a given location, it seems unable to detect the full 6GB, starting to swap to system RAM at anything over 4GB, which is the value set by the viewer as MINIMUM texture memory if I use the Dynamic Texture Memory management in the viewer.

    It almost seems to regard that 4096MB value as not the MINimum VRAM availablr to the viewer  but the MAXimum, above which my system RAM is deployed (I have 32GB of 3200MHz RAM on my system which is substantially more than I am ever likely to use).

    Now that "spillover" into system RAM is not a problem capacity wise (I have never seen the viewer use much more than 8GB), it causes stutters if I actively cam around at a busy venue (such as at a poplular club.  Setting a lower quality is actually counter productive under "high" and I always use the Advanced Lighting Model.

    So far I have NOT observed such issues on the Linden Viewer, though setting that horrible device up has given me the heebies, and since you cannot set dynamic memory management up in the LL viewer (or at least I'm not able to find the setting in debug), the comparison is invalid.

    I should say in addition that I have used FS with dynamic texture memory deactivated, and while I see no stutters I get substantial texture thrashing, though not of moving textures, ie those attached to avatars.

    So far I have no solid conclusions and the support team at FS, while being initially helpful, have added nothing to my understanding of the phenomenon.

    ETA: By the way the 1660Ti is my ONLY GPU.

    FETA: Using the latest Linden Viewer (6.6.10) I observe the  viewer uses a LOT less RAM in a given situation but due to the ridiculously low level of texture memory this viewer uses (512MB) which cannot be increased  via Debug (I tried), the texture thrashing observed was considerable but over a short test in a challenging scene no stuttering was observed.

  4. @Paul Hexem You don't annoy me, Paul, I am simply at a loss to understand why:

    1)  You never actually characterised the nature  of your "crashes" preferring, it would seem, to raise further red herrings.

    2) You discount or ignore several others' clearly different interpretations of your experience.

    3) You appear to discount the assertions of others that your experience is neither widespread nor considered critical, except perhaps to yourself.

    Your experience is valid as it stands for you personally, but apparently no reasonable explanation is acceptable to you.

  5. I confess to being a bit annoyed with the poor user-facing responses from LL of late.  If it wasn't for @Monty Linden, there'd be nothing apart from @Logan Elf's valuable info. 

    Especially since the migration to 579248 appears to have introduced some unexpected behaviour changes on TP that were not flagged up after the RC channels rolls.

    The changes are not (so far as I can see) damaging, just startling. I refer to intra region TPs not triggering the blackout teleport screens, which is a quite  a surprise on first encountering it!  It could be that the apparent change is confined to Firestorm users...I must check.

    ETA: so it seems it is confined to any viewer that permits you to disable the TP screens etc, so most likely FS only.  It may be something to do with my particular graphics setting too so I was getting my virtual knickers in a twist over nothing.  Got to say that a TP down from my skybox at 900m to ground level is not for sufferers of vertigo!

  6. @Paul Hexem  are you really talking about a viewer crash or do you mean the disconnect that occurs when the destination region of a teleport fails to accept the data sent by the source region?  That issue has persisted in varying degrees for the lifetime of SL, and the appearance of the greyscale screen with its options to "read IM or quit" is just as familiar to users now as it was 15 years ago.  That phenomenon is seemingly beyond the wit of Linden Lab to reliably fix, though the frequency of disconnects has noticeably increased again recently.

    If your viewer actually crashes to desktop, as Nal suggests, you have a local issue.  I experience occasional viewer crashes and very occasionally ones that do not trigger the bugsplat error report, but not at a frequency that I find alarming.

    • Like 4
    • Thanks 1
  7. @Aimena  your issue seems specific to either your location or your computer.  Were you logging in at a relative's house using your own  computer (a laptop I assume)?

    If so I would suspect your router or the WiFi signal it produces.  Can you go hard-wired at your home address?  That would be worth a try.

    Simply turning of the router unplugging it for AT LEAST 2 minutes then rebooting it may help. 

    ISPs do make changes to individual connections at times and with WiFi even moving the furniture in your house can interrupt the signal, it is THAT flaky!

  8. @StilettoSarayou are by no means the first to bemoan the passing of that feature (which has been gone for quite some time now).

    I suggest that you pester Linden Lab over this by making a "feature request" via the LL jira system, since it will not return unless LL change the viewer.

    https://jira.secondlife.com/secure/Dashboard.jspa?

    While you will undoubtedly garner much support in this forum, LL will not act on words written here.

    • Like 1
  9. I hope I am not being previous in saying this but after some (not a great deal and with a fairly full texture cache) testing on some tricky textured areas under moving shadow conditions, when I turn off dynamic texture memory and rely simply on the value given by my viewer ie 2048MB, I am getting a much less jerky and hesitant rendering that I would call smooth and no obvious penalty in either quality or FPS.

    Of course I need to do further testing in challenging situations but these initial results are both surprising and encouraging almost in equal measure!

    This is using Firestorm 6.6.8 release on Windows 10 with 32GB RAM, CPU is Ryzen 9 3900X, GPU Nvidia GTX1660Ti (6GB VRAM)

  10. I have encountered this issue in recent days, I checked my GPU use and saw no unusual activity, other than a high level of activity of reads and writes to the texture cache, during which activity, the render process appeared to be suspended.  There was no activity from either my OS or my AV, which is fully and correctly set up to "whitelist" any and all viewer functions.

    The phenomenon appears to be associated with busy locations with a large  number of animated (dancing) avatars.  As a consequence I had put the issue down to the performance of my GPU (Nvidia GTX1660Ti), I am now wondering what its cause is.

  11. All the above leads me to suggest that it is your firewall or antivirus programme that is blocking the executeable file that is used here...I think it maybe "dullahan-host.exe" it is either being blocked by the AV or by your computer firewall.

    Usually during installation te setup wizard asks you to enable access for this and several others.  If it is blocked or even removed most things work except search and few related applications within SL.

    You will need to redownload and reinstal the viewer making particular note of the requests for access.  Only download viewers for repuatable websites such as Second Life or  Firestorm (or the other 3rd party viewers listed in the Third Party Viewer list.

    ETA: To my knowledge updating Flash, Java or Apple's Quicktime is not required and has not been for some time.

    Advice for Antivirus white listing is as follows, second line on is applicable for all viewers, first line will depend in whichever viewer you are using.  Otherwise the name of the viewer will replace Firestorm after C:\Program Files\

    The Files you need to add:
    C:\Program Files\Firestorm-Releasex64\Firestorm-releasex64.exe
    C:\Program Files\Firestorm-Releasex64\slvoice.exe
    C:\Program Files\Firestorm-Releasex64\slplugin.exe
    C:\Program Files\Firestorm-Releasex64\llplugin\dullahan_host.exe

  12. First of all, Moon, which viewer do you use?  If Firestorm it maybe that some of the streams are blocked in your media filter if you use it (look in Prefs>Sound and Media>Sounds> Manage Media Sites).

    However unlikely it may sound, some antivirus setups regard certain urls as being malicious and block them.  I have no idea how to correct that short of talking with your AV vendors helpline.  That list is frequently updated so what was allowed last week might be blocked this week!

    There are other causes but I'll leave the explanation of those to folk who are far more expert than I.

    • Thanks 1
×
×
  • Create New...