search

secondlife / jira-archive

2 stars 0 forks source link

[BUG-2514] Dam Textures wont stay fully rezzed or don't fully load at all - FUZZY DETAIL #11835

Open sl-service-account opened 11 years ago

sl-service-account commented 11 years ago

Steps to Reproduce

I dont know how to reproduce, it happens at random, there seems no specific thing that triggers it other than being logged on.

I first thought this was happening because i was using big 1024 textures on big mesh, but its happens on mesh, on prims, with small textures as well as big textures.

I thought maybe it was a mac only issue but others have stated they get the issue as well. Perhaps its related to a specific graphics card make. I will ask around.

Here is a video showing the Fuzzy Detail Issue happening on Main release Viewer in New Babbage. It is a 256 x 512 texture on a very low poly Mesh Picture frame with two faces.

http://telly.com/J0WTD6

Actual Behavior

This has been an issue that has been around for a while but over the last month it has become unbearable for me so im now writing the bug report.

In fact there are a number of texture related issues that may or may not be related. I dont fully understand how textures are loaded into the viewer. Visually we are given the impression that as the texture loads is first presents a lower detailed version and as it loads more we get more detailed until fully loaded into cache and presented full detail.

The issues im having.

  1. The textures sometimes appear to stall when loading and stop at a lower blurry detail. ReLogging can sometime force the texture to reload.

  2. Nearly all textures are starting to exhibit a tendency to once fully loaded flicker to being less detailed as if they are being re-downloaded again even though they should be in the cache.

Its getting progressively worst to the point where i cant film machinima because I'm surrounded by flickering fuzzy textures.

Expected Behavior

I would like the texture to load full detail and stay full detail like the good old days.

Other information

Attachments

Links

Related

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-2514 | | Summary | Dam Textures wont stay fully rezzed or don't fully load at all - FUZZY DETAIL | | Type | Bug | | Priority | Unset | | Status | Needs More Info | | Resolution | Unresolved | | Reporter | Loki Eliot (loki.eliot) | | Created at | 2013-05-06T12:04:15Z | | Updated at | 2021-03-31T21:52:20Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2013-05-06T10:16:02.413-0500', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': "This has been an issue that has been around for a while but over the last month it has become unbearable for me so im now writing the bug report.\r\n\r\nIn fact there are a number of texture related issues that may or may not be related. I dont fully understand how textures are loaded into the viewer. Visually we are given the impression that as the texture loads is first presents a lower detailed version and as it loads more we get more detailed until fully loaded into cache and presented full detail.\r\n\r\nThe issues im having.\r\n1. The textures sometimes appear to stall when loading and stop at a lower blurry detail. ReLogging can sometime force the texture to reload. \r\n\r\n2. Nearly all textures are starting to exhibit a tendency to once fully loaded flicker to being less detailed as if they are being re-downloaded again even though they should be in the cache.\r\n\r\nIts getting progressively worst to the point where i cant film machinima because I'm surrounded by flickering fuzzy textures.", 'What were you doing when it happened?': 'I first thought this was happening because i was using big 1024 textures on big mesh, but its happens on mesh, on prims, with small textures as well as big textures.\r\n\r\nI thought maybe it was a mac only issue but others have stated they get the issue as well. Perhaps its related to a specific graphics card make. I will ask around.\r\n\r\nHere is a video showing the Fuzzy Detail Issue happening on Main release Viewer in New Babbage. It is a 256 x 512 texture on a very low poly Mesh Picture frame with two faces.\r\n\r\nhttp://telly.com/J0WTD6', 'What were you expecting to happen instead?': 'I would like the texture to load full detail and stay full detail like the good old days.', } ```
sl-service-account commented 11 years ago

Whirly Fizzle commented at 2013-05-06T15:16:02Z

Heya Loki,

Many people who have this problem are helped by disabling HTTP Textures.

Enable Develop menu in top bar with CTRL+ALT+Q Then Develop -> HTTP Textures -> Untick this Then relog.

Does this help at all?

sl-service-account commented 11 years ago

Loki Eliot commented at 2013-05-06T18:50:54Z

No, HTTP Textures does not make any difference,

sl-service-account commented 11 years ago

Whirly Fizzle commented at 2013-05-06T20:11:35Z

Blurry textures issue is also reported on BUG-2488

sl-service-account commented 11 years ago

Whirly Fizzle commented at 2013-05-06T23:40:21Z, updated at 2013-05-07T00:55:00Z

I came across a mesh build today that constantly reloaded textures for everyone using either current Viewer 3, current viewer 3 beta or Firestorm.

https://marketplace.secondlife.com/p/VandeloVictoria-housefull-furnished/4662391

This build is rezzed here: http://maps.secondlife.com/secondlife/Seraphim/217/202/1514 EDIT: Possibly not rezzed for much longer. The owner is replacing the skybox because its unusable because of the texture issue. EDIT2: The build is rezzed at the shop here: http://maps.secondlife.com/secondlife/sau/129/224/23

Hang around in the above build for a few mins and observe that many of the textures constantly unload/blur and then reload/sharpen over and over. This is particularly evident on the sofas and cushions and items on the table.

In the above case I suspect not much can be done - the build is gorgeous but not optimised at all. Even the tiny teacups are 1024x1024 textures.

sl-service-account commented 11 years ago

Monty Linden commented at 2013-05-09T20:11:53Z

I looked at region 'sau' quickly and that's definitely a detailed build. What I saw was GL texture thrashing as the mouse moved around. My graphics card is old (512MB) and fills to limit and as focus moves from object to object, something gets evicted. What the viewer is choosing may not be the best and it does seem to hit the network so caching may have issues. Build was dense enough to get 503'd on both meshes and textures when it starts loading.

sl-service-account commented 11 years ago

Loki Eliot commented at 2013-05-13T11:01:54Z

It is a relief that this issue has been observed by others. I was wondering wether it could be explained what 'texture Thrashing' is exactly in order to improve my own understanding. When i build my own creations i try to keep total textures to a minimum and also try to use textures appropriate to size of object in world. Of course all this optimisation stands for nothing if my build is next door to something like what Whirly has exampled above. So is the issue something to do with viewer cache or is it down to creator inefficiency?

sl-service-account commented 11 years ago

Alexa Linden commented at 2013-05-15T21:08:28Z

Hi Loki are you seeing any improvement with the lastest beta build?

sl-service-account commented 11 years ago

Loki Eliot commented at 2013-05-15T22:25:10Z

using beta Second Life 3.5.2 (275653) small faces textures are fuzzy until you mouse over for 2 or 3 seconds which is alot better than before when they would never rez full detail. They don't appear to flicker in and out of detail once loaded as shown in my video which is good. So yes this beta is a great improvement thanks.

Large faces,like for instance the side of a building thats 30m x 30m still tend to flicker in and out of detail as i walk past. Is this an effect related to how LOD or Interest list works?

sl-service-account commented 11 years ago

Loki Eliot commented at 2013-05-15T22:32:30Z

The mouse hover trick does not work with my mesh clothes though.

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-10-17T14:36:35Z

Torley has been enjoying the texture thrashing experience with the Vandelo builds :D https://my.secondlife.com/torley.linden/posts/5440cf6176286532390000ad

sl-service-account commented 9 years ago

Torley Linden commented at 2014-10-17T14:55:28Z, updated at 2014-10-17T14:57:10Z

Yes, I have been noticing this more frequently while filming recent Second Life videos. It's true I often look for locations that are dense with detail and have many high-resolution textures. However, I'm on a NVIDIA GTX 680 that has 1.5 GB of memory, though I observe the texture memory slider in the Viewer's Graphics Preferences is capped at 512 MB, even if I try to change "TextureMemory" in DEBUG SETTINGS.

http://maps.secondlife.com/secondlife/Vandelo%20Design/135/19/24 is a very, very obvious location where it happens for me. It's true build optimization could be done, but that isn't an obvious and well-understood fact for the casual visitor. It would be helpful to have more continuing education and awareness (e.g., update and promote http://wiki.secondlife.com/wiki/Texture_Usage ).

(Disabling HTTP Textures doesn't make a difference for me, either.)

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-10-17T15:05:52Z, updated at 2014-10-17T15:06:15Z

Torley, as far as I'm aware LL is working on allowing a larger texture memory then 512MB, which should help with this problem a lot for users with graphics cards with larger memory. Creators do need to be more aware of optimising the texture sizes used on their builds though - far far too many builds use 1024x1024 sized textures where they just are not needed.

An initial stab at allowing higher texture memory was done here: https://bitbucket.org/lindenlab/viewer-tiger/commits/8425f76bbb1de290c9c4956a2e0579d4a05a0112 However it was backed out due to problems (BUG-6207 was one problem caused by that change).

sl-service-account commented 9 years ago

Torley Linden commented at 2014-10-17T15:27:57Z, updated at 2014-10-17T15:34:31Z

Thanks Whirly, I recall hearing that or a similar link before. I wonder about the feasability/usefulness of an auto-downsample feature that sets max texture resolution to 512x512, depending on how far you're zoomed out and other (interest list?) priorities.

I have not noticed appreciable gains when "Enable Texture Compression" is on, either — that's another feature that isn't too well-understood.

EDIT: I've attached a video of what I see: https://jira.secondlife.com/secure/attachment/83102/Textures%20keep%20reloading%20bug%2C%20BUG-2514.mp4

sl-service-account commented 9 years ago

Monty Linden commented at 2014-10-17T18:32:42Z, updated at 2014-10-17T18:33:21Z

So, in something like game development where one hierarchical team would make resource decisions, a resource target would be set (say 256MB resident textures) and content would be adapted to fit in it. Doesn't work for us where content is designed without foreknowledge of its target environment. Better tools for the content creators is certainly desperately needed. Has been, is now, will be tomorrow.

But it's not enough. That centralized feedback loop within a design team doesn't have a direct analog in SL. Instead, there are many independent possible feedback loops. Estate owners/managers and event/build organizers might want the resource allocation and enforcement role. Renters, visitors, fabricators, etc. are directly and indirectly consuming it. The piece that is missing is the communication/advice/enforcement/review network so that everything can be brought into balance. Prim/rendering cost doesn't quite cover it.

Recent changes are probably going to aggravate it. Mesh and texture behavior just became a whole lot more permissive. I'm expecting overbuilding to become more common.

sl-service-account commented 9 years ago

Torley Linden commented at 2014-10-17T23:07:30Z, updated at 2014-10-17T23:26:34Z

That's a great way to put it, Monty — the "communication/advice/enforcement/review network" is the social-cultural piece of the puzzle. I have always advocated for this in SL and am more than happy to help if we (Linden Lab) are going to raise awareness, especially at a broad level that sets a good example of content creation practices. It's incredibly important to teach our community how to get the most out of any tools and to be aware that resource usage needs to be balanced for optimized experiences.

I wish the LL Viewer had a better way to selectively block/hide objects during a session. There are times when it's several troublesome objects stuffed with 1024x1024 textures that cause problems for the rest of the scene. This is even more evident when doing video work since the "texture thrashing" is recorded in motion, and really makes the experience look bad. Some 3rd-party viewers have a "Hide Selected" that persists until you either relog or teleport away and back again.

Texture thrashing is even more problematic considering that (1) some of the best-looking scenes in SL are very graphically dense in order to maintain a more modern appearance and (2) sometimes, it's a curated collection of objects built by an assortment of creators, gathered in a cohesive space — so the content curator doesn't have full control over those texture sizes aside from choosing what they include.

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-10-18T13:42:41Z

Loki, would you mind setting this issue to Public security level so those following the discussion on Torley's feed can see this? Thanks!

sl-service-account commented 9 years ago

Loki Eliot commented at 2014-10-18T14:03:48Z

Roger Roger

sl-service-account commented 9 years ago

Monty Linden commented at 2014-10-20T18:23:51Z

There are a number of projects here of various sizes. I might also want to do some archaeology. I can imagine someone started down this path a long time ago and left some treasure for us somewhere.

sl-service-account commented 9 years ago

Samm Florian commented at 2014-10-23T02:56:06Z

Crazy idea, maybe, but here goes. When I was a newbie builder, I didn't have a lotta Lindens to spend on downloads, and if I uploaded a texture I wanted to get the biggest bang for my buck. Why upload a texture as 128x128 when I might want to use it on a bigger object someday? What might help is if there was a way to take an uploaded texture, and create a buncha downscaled textures from it for free.

Or here's another idea: a new setting in the Texture panel: restrict textures on this surface to a maximum resolution of 128 or 256 or 512, or no restrictions. That might be even better, 'cause then you could take somethin' already built with huge textures, and easily make 'em friendlier.

Third idea: make 1024x1024 textures count against land impact.

sl-service-account commented 9 years ago

wendi.nitely commented at 2014-12-15T20:36:51Z

This texture thrashing does not occur in a freshly downloaded and unmodified Firestorm 4.6.9.42974 (64-bit). This problem does occur in Second Life 3.7.23 (297296) even with HTTP textures un-checked.

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-12-15T21:06:43Z

It does happen on Firestorm, believe me - we get lots of complaints from Firestorm users about texture thrashing. However, it doesn't happen as frequently on Firestorm as on the Linden viewer - taking a guess I'd say that's because of http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/3a4c4907089f

sl-service-account commented 9 years ago

wendi.nitely commented at 2014-12-15T23:18:25Z

I understand Whirly, what I should have said it while I tested I did not experience it while waiting long enough to have expected to see it based on my Second Life 3.7.23 (297296) experience.

However this is what I tried with Second Life 3.7.23 (297296), was set the debug setting RenderTextureMemoryMultiple to 2.0 (I have 2GB of video memory). If I understand this correctly that allowed me to use 1024mb for textures. When I reclogged in I found all the textures rezzed immediately, look more crisp than I ever remember seeing them.

OK, so they do occasionally re-rez, not nearly as often, so it isn't a "fix". But it made an improvement and perhaps might provide another clue as to what is happening. This is certainly effecting the quality of (second) life.

sl-service-account commented 9 years ago

wendi.nitely commented at 2014-12-15T23:28:20Z

OK, so this may not have as much a positive effect as I was hoping. But Whirly, am I wrong in thinking this is a systemic problem... that really there isn't much we can do until Linden Labs addresses the issue?!

sl-service-account commented 9 years ago

wendi.nitely commented at 2014-12-15T23:34:11Z

I can also add that in my case disabling VBO doesn't seem to have any positive effect.

For those of us doing in-world still photography and video, this is a serious problem.

sl-service-account commented 9 years ago

mia3001 commented at 2015-02-13T09:52:45Z

I find this texture problem very disturbing because it happens on one of my accounts, but not the others so I know it is not my computer or viewer. All of them have the same preferences set????

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-02-14T00:45:11Z, updated at 2015-02-14T00:48:49Z

@mia3001 Is the affected account wearing texture heavy HUDs or attachments? Texture heavy HUDs are the worst culpret because HUD extures always load at full resolution (discard 0). There are some very popular HUDs known to cause almost instant texture thrashing when worn - The Shops! Styling HUD & shopping HUD, the Wowmeh avatar HUD & the Toddleedoo avatar HUD. See BUG-6242 & http://jira.phoenixviewer.com/browse/FIRE-13904

sl-service-account commented 9 years ago

mia3001 commented at 2015-02-14T09:36:12Z

Looks like you figured it out Whirly Fizzle. This account is a child avatar and is wearing the Toddleedoo Hud... darn it!

sl-service-account commented 9 years ago

wendi.nitely commented at 2015-02-14T17:16:53Z

So now users of the Toddleedoo Hud know what is at least a contributing reason for their texture thrashing. But this is a very common and seemingly systemic problem that needs to be resolved in server and/or client software.

sl-service-account commented 9 years ago

Quinlan Placebo commented at 2015-07-09T18:45:56Z, updated at 2015-07-09T18:47:49Z

did not mean to post here... sorry :P

sl-service-account commented 9 years ago

Monty Linden commented at 2015-07-09T19:03:37Z, updated at 2015-07-09T19:16:48Z

"Nevermind." - Roseanne Roseannadanna?

(For the record, it was a fine rant. Hope to see it in its intended context.)

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-05T23:07:13Z, updated at 2015-08-05T23:07:31Z

@Monty

I'm curious what causes almost instant texture thrashing when standing inside the "Apple Fall Hardwick Manor" build at this location: http://maps.secondlife.com/secondlife/Fields/74/103/22

Within a minute of entering this location, I get texture thrashing on Second Life 3.8.2 (303891) Jul 28 2015 12:10:43 (Second Life Release), yet on the texture console, my GL Tot reading will show the first number less then the second number, yet bias is at 5.

Texture console 1 min after login at that location & my Bias is already at 5.0 & I see thrashing: http://prntscr.com/81bcnq

Even on Firestorm 64bit, which allows me to set 1024MB texture memory, I still get almost instant texture thrashing: http://prntscr.com/81bey4

There is some discussion about this build on Plurk: http://www.plurk.com/p/l4xt26

sl-service-account commented 9 years ago

nagachief.darkstone commented at 2015-08-11T12:11:00Z

The texture thrashing has gotten worse to the point that due to my poor internet, it has caused Second Life to become unusable. None of those discarded textures make it into the cache, which means they instantly try to be redownloaded on my poor quality 1.5 MBit net. It has gotten to the point where simply using SL wrecks the entire network to the point no one else can do anything. I preferred it when Second Life would just simply bog down and start to chug along because it never unloaded textures.

If no solution is found soon I may have to abandon Second Life and take my premium sub with me as I'm no longer having an acceptable and usable experience as both a resident and a content creator.

sl-service-account commented 9 years ago

Monty Linden commented at 2015-08-12T05:31:37Z

I spent a little time this evening in Apple Falls (sharing the region with Commander ButtCheeks) using my old GTX 660 Ti Win7 machine. A piece of the Texture Console is captured in the jira2514_applefall image. In my case, the GL Tot and MB Bound thresholds are exceeded and MB Bias is run up to 5.0. This condition will persist for awhile. Then there's a trigger event which ejects textures, drops Bias to 2.5 and begins reloading textures from cache. Sometimes running up over thresholds again, sometimes staying at or below thresholds. Don't know what the trigger is, may be an interest list change (camera, avatar, etc. activity), may be a timer event (possible 300S timer).

A test with short draw distance (64m) and texture compression enabled may have given a little headroom but not much.

It appears that the content in that region, combined with the limits of the texture handling parameters, just doesn't permit a stable texture fit on some hardware. The texture packing logic isn't one of my areas so I'm not certain about ways to control this and override the behavior. I'm also not certain I believe the bias implementation...

@Nagachief All of the above involves moving textures between the grpahics card and on-disk cache. If you're seeing network activity to load textures, you may have a separate problem. (See, for example, the 'Tot Htp' field in http://wiki.secondlife.com/wiki/Texture_Console.) The 'Cache' field on the first line may give a hint if you need to increase the texture cache size.

sl-service-account commented 9 years ago

nagachief.darkstone commented at 2015-08-12T17:45:56Z, updated at 2015-08-12T18:06:41Z

I have texture cache size set to the highest it can go. Even with a fresh cache, if textures unload from hitting VRAM cap, it appears to act as if it never made it into the local cache.

I've bugged one of the Alchemy devs to redo that apparently 'unstable' fix he made some time ago to a test build. VRAM slider was raised to 2 GB. Again, it gave a massive improvement in both stability and lower network usage. Side effects though is that in a large club or highly detailed scene you'll quickly cause the entire system to become unstable if you set it above your GPU's physical VRAM size. For me, this is a reasonable compromise due to my network issues.

Might I suggest mirroring this fix on the main viewer? Maybe with a red 'This may cause system instability!' warning box if you set it above 512mb?

Another suggestion is maybe with advanced settings enabled, add a dropdown box called texture quality. where Medium is 512MB, High is 1GB, and Ultra is 2GB VRAM.

sl-service-account commented 9 years ago

Monty Linden commented at 2015-08-12T18:12:37Z

Might I suggest mirroring this fix on the main viewer? Maybe with a red 'This may cause system instability!' warning box if you set it above 512mb?

This is going on my wall ("User demands more instability!"). :-)

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-12T18:41:36Z

On the 64bit build of Firestorm we allow the user to set the texture memory slider up to 1024MB (2GB max textures in memory) and it really does make a huge difference for me. On the LL viewer I suffer from texture thrashing on a daily basis. On Firestorm 64bit, I do still get texture thrashing in certain locations (like the location I gave above) but it happens a lot less - I'll maybe see it a couple of times a week in certain texture heavy locations where there are lots of avatars, rather then every day on pretty bare regions, which I suffer from on the LL viewer. On the LL viewer, I even suffer from texture thrashing on Testylvania Sandbox, which is an almost empty region, if I have shadows enabled (Shadows very definitely make the problem worse). The thrashing will start about half an hour after logging in (I suspect the mini profile icons are what's causing it to even happen on an empty region if I have a lot of busy group chats open... those can eat up a good 200MB texture memory :/)

We did try to allow a higher texture memory setting on the 32bit build of Firestorm but it was a disaster and it was removed. It caused users (especially those on 32bit systems) to suffer very frequent out of memory crashes. On a 32bit system the viewer only has 2 gig memory to play with - if you take 1 gig away for texture memory, there just isn't enough left - my inventory alone takes ~ 700MB of memory (110k items).

For reference, these are the changes made to Firestorm to allow setting a larger texture memory on the 64bit builds only, including bug fixes (one which sounds like it may be a fix for the performance issue you mention Nagachief).

So far we haven't seen any stability problems on the 64bit build after these changes.

If the max allowed texture memory could be safely raised on the LL viewer (being that it's 32 bit..) I'd be all for that!

My system info:

Second Life 3.8.2 (303891) Jul 28 2015 12:10:43 (Second Life Release)
Release Notes

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.96 MHz)
Memory: 16268 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 750/PCIe/SSE2

Windows Graphics Driver Version: 10.18.0013.5362
OpenGL Version: 4.5.0 NVIDIA 353.62

libcurl Version: libcurl/7.38.0 OpenSSL/1.0.1h zlib/1.2.8
J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
Qt Webkit Version: 4.7.1 (version number hard-coded)
Voice Server Version: Not Connected
Built with MSVC version 1800

Card details: http://prntscr.com/83vf57

sl-service-account commented 9 years ago

Monty Linden commented at 2015-08-14T22:23:32Z, updated at 2015-08-14T22:36:37Z

What is actionable from this last round of comments:

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-14T22:55:39Z

For the profile icon issue, also see BUG-9418

sl-service-account commented 9 years ago

nagachief.darkstone commented at 2015-08-15T02:18:24Z, updated at 2015-08-15T02:22:04Z

@Monty Linden I'll need to check but Alchemy and Second Life are far, far closer to each other than Firestorm is. When I get the chance I'll test a bit to see if it has the same behavior. And the saving failure only happens during thrashing, otherwise it loads from local cache. It does confuse me because textures I already have in the cache load fine until thrashing occurs then it behaves as if there is no cache. I don't know if it's rapid calls to the server overwhelming my low end net due to my cache being on an SSD that loads textures instantly or if it really is forgetting it exists.

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-15T02:34:06Z

Is there some way to test whether textures exhibiting thrashing are being redownloaded again from the server or are loading from local cache? If I understand Nagachief correctly, she's saying textures that are thrashing are not loading from local cache? I can test that too on the LL viewer if someone can tell me how to check that.

If I purge my texture cache & login on the LL viewer & wait for texture thrashing to start, the thrashing textures I know the UUID for are certainly in my texture cache when I check.

sl-service-account commented 9 years ago

Monty Linden commented at 2015-08-15T04:34:49Z

Is there some way to test whether textures exhibiting thrashing are being redownloaded again from the server or are loading from local cache?

There is! It's not 100% but at the end of the first section of the 'Texture_console' wiki page linked above (the "Some patterns to look for..." paragraph) are some ways to understand cache and HTTP behavior.

I'm skeptical about texture thrashing leading to HTTP refetches in the Linden viewer. We have had some stunning bugs around cache failures. And the texture cache index has some undocumented limits which cap it before the cache preference limit is hit. But the cache should remain valid unless something terrible is going on. Cache writing is fairly independent from texture loading into OpenGL.

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-15T12:26:21Z

I dont seem to be able to reproduce it on Second Life 3.8.2 (303891) Jul 28 2015 12:10:43 (Second Life Release) or Firestorm 4.7.3. I was too bored at the end of this to test Alchemy ;) I think my readings are normal, but not 100% sure, so you get graphs :D I autocaptutred a screenshot of texture console every 5 or 10 secs.

On LL viewer, Second Life 3.8.2 (303891), using default settings apart from Max BW 1500, draw distance 512, cache size max, graphics quality defaults to High-Ultra on my card, Texture memory defaults to 512 MB on my card.

Location where I get almost instant texture thrashing

I used the Apple fall house from above: http://maps.secondlife.com/secondlife/Fields/74/103/22

Location where there was no texture thrashing

I used TextureTest2 No mesh on this region if that makes a difference?

Still on TextureTest2, I wanted to see what would happen when TextureLoadFulleRes was set to TRUE. This is a setting people often enable >.< Texture memory was set back to default (512). As expected, results were horrid - bias went up to 5 pretty fast and textures thrashed. FPS also dropped dramatically (from ~ 75 down to 4 when the bias went to 5).

Second Life 3.8.2 (303891) Jul 28 2015 12:10:43 (Second Life Release)
Release Notes

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.91 MHz)
Memory: 16268 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 750/PCIe/SSE2

Windows Graphics Driver Version: 10.18.0013.5560
OpenGL Version: 4.5.0 NVIDIA 355.60

libcurl Version: libcurl/7.38.0 OpenSSL/1.0.1h zlib/1.2.8
J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
Qt Webkit Version: 4.7.1 (version number hard-coded)
Voice Server Version: Not Connected
Built with MSVC version 1800
sl-service-account commented 9 years ago

Monty Linden commented at 2015-08-15T17:50:38Z

@Whirly Thanks for the data collection! But boring? Data! Collection! Graphs! Repeat! This is la dolce vita...

Session 1, Clean cache, TextureLoadFullRes TRUE: http://i.imgur.com/MA54JEj.png

Title on this one may be bad, image suggests fully cached. I'm trusting the report here since this is the TT2 region (known content).

Some observations:

  1. Disk cache appears to be more or less normal. Cache writes match fetches which are approximately where I'd expect them for hot/cold caches. There's a constant background activity which always bothers me. May be profile icons or something else but I'm going to ignore it for the moment. (Kind of want a debug setting to completely disable these icons...)

  2. 'Fields' region has far fewer textures than 'TT2'. Partly because the latter is a completely artificial test region. Also implies that 'Fields' is using large textures. I suspect I'm going to find a lot of 1kx1k if I crack it open.

  3. New finding: there appears to be a significant delay from completing an HTTP request and cache being written. This is based on a 1:1 assumption which isn't really true. Shouldn't affect framerate, thrashing or other things. But interesting.

So I don't think thrashing is having an impact on disk cache validity in the Linden viewer.

I think the thrashing case does go back to disk cache but there are some very flat plateaus in the Cread graphs. Whirly, do you know if thrashing was going on during these time ranges:

If so, viewer was operating out of the in-memory cache rather than having to go back to disk.

(Texture caching has many layers. From your eyes back:

Thrashing is mostly excess activity between the first two.)

sl-service-account commented 9 years ago

FL0 Cale commented at 2015-08-15T19:10:31Z

I have been following this for quite some time now but i thought it would be worth mentioning that I've seen this problem happening since the introduction and deploy of HTTP textures code in the viewers. Turning HTTP Texturing off in the viewer doesnt have any effect though.

Back then I was using an Nvidia GTX460 and that videocard would have massive problems with this "bug". The form it would behave is that it would constantly reload the textures (not only on some SIMs but pretty much everywhere). It would then suffer from major FPS drops once the textures were all loaded then as soo as the textures started going blurry again the FPS would go up. It would do that every few seconds. Eventually i moved on to the GTX780 and the reloading texture issue while still there became less annoying because there would be no FPS drop.

There is a Jira about this issue on the phoenixviewer jira and i even commented on it ancd Whirly might remember it too: http://jira.phoenixviewer.com/browse/FIRE-8562

I know it's kind of a seperate problem perhaps but I am convinced it is related due to the timing of it happening. My GTX460 did not behave that way prior to the HTTP texture deploy. I just thought i should mention it here.

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-16T03:32:37Z, updated at 2015-08-16T03:35:33Z

Title on this one may be bad, image suggests fully cached. I'm trusting the report here since this is the TT2 region (known content).

Oh blarg - I think I mistitled the graph there but I'm not 100% sure.

There's a constant background activity which always bothers me. May be profile icons or something else but I'm going to ignore it for the moment.

Yes, every session I made the graphs for I had several large group chats opening and those damn profile icons were loading. I should really use an alt to do these kinds of tests who isn't in any groups - I'll do that from now on.

For example, the TT2 fully cached graph: http://i.imgur.com/wgf68TT.png The new surge of textures appearing at 40-60 secs was a large group chat that opened loading all the profile icons.

Also implies that 'Fields' is using large textures. I suspect I'm going to find a lot of 1kx1k if I crack it open.

Theres quite a lot of 1024x1024 textures on that region. Hard to show in an image, but: http://prntscr.com/854x8k

  1. New finding: there appears to be a significant delay from completing an HTTP request and cache being written.

I noticed that. Could that be my hard drive or antivirus software slowing things down by doing real time scanning? My LL viewer cache was in default location (fast SSD drive)

Whirly, do you know if thrashing was going on during these time ranges:

Fully-cached from 140-220 Clear Cache 130-170, 210-end

I'm not sure which graphs you are refering to there. All sessions on the Apple Fall region had constant thrashing (& bias 5) from about 30 seconds onwards.

When doing all the tests, I logged into the same location & didn't move my avatar or camera at all. I couldn't really follow what was going on if I moved my avi/camera because once the texture console had cleared (ignoring the constant appearance of profile icons...) when I changed camera view, the texture console would fill up again & bias would sometimes drop down to zero and then raise to 5 again.

There is also a weird thing that still happens when the 1st number in GL Tot reaches ~2000. That 1st number changes to a negative value & stays negative & bias drops down to zero and remains at zero. Texture thrashing still happens when bias sits at zero though. See image on last comment on BUG-6786 for an example.

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-16T03:45:03Z

If so, viewer was operating out of the in-memory cache rather than having to go back to disk.

Is "in-memory cache" the Fast cache? FastCacheFetchEnabled in debug settings?

sl-service-account commented 9 years ago

nagachief.darkstone commented at 2015-08-16T08:01:43Z, updated at 2015-08-16T18:05:52Z

If what has been found out is true for alchemy as well, I might have an odd theory. I've heard some time ago high end computers caused simulator issues because client to server communication was linked to fps. Maybe my textures are making it to my local cache, but my viewer is sending/receiving texture fetch requests as fast as my framerate and thus saturating my internet.

My cache is on a high performance SSD so local requests are near instant, maybe this is tripping up the client/server?

While back in a desperate move to attempt to get SL to use less bandwidth I 'broke' texture downloads by setting max fetch request for all priorities to 1 and discard lowest. It kinda worked, used far less bandwidth but essentially caused textures to never load or load very slowly. Since I kinda need textures I set everything back to default afterwards.

sl-service-account commented 9 years ago

Monty Linden commented at 2015-08-16T23:05:48Z

Is "in-memory cache" the Fast cache? FastCacheFetchEnabled in debug settings?

No, all textures used in a session live in memory, at least for certain periods of time. And necessary for loading anything on the graphics card. The 'FastCache' appears to be (I had to look at the code) some kind of magical, special early lookup of texture images for certain cases. Seems to be lacking some documentation...

sl-service-account commented 9 years ago

Theresa Tennyson commented at 2015-08-17T00:58:08Z

I've found another mesh build that causes near-instant, inexplicable ballooning of texture memory - a building available only as a gacha rare item from Ionic.

It's called "ionic Motel - RARE"

I tried editing it using "Select Face" and quickly noticed something strange. On many of the walls and other surfaces, instead of showing the texture you'd expect to see those faces show up with a completely transparent, alpha blended texture. It's as if many walls have some invisible skin over them for no obvious reason - it may be an artifact of how the build was made and/or a glitch created during the importation process. It's possible a number of mesh buildings have these mystery faces and the load caused by the unnecessary alpha blending may be increasing the texture memory used. I haven't experimented with modifying these faces as it's a no-copy building.

You can see the build showing these issues at: Sandpiper Motel, Schreckhorn (62, 240, 85) - Moderate

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2015-08-17T13:55:34Z

I can reproduce texture thrashing easily at Theresa's location on current release: http://prntscr.com/85h6xv Thrashing starts about 2 mins after logging in there.