PROPOSAL: Texture memory increase

[kiramanell]

I own several high-quality, materials-enhanced mesh homes. Whilst beautiful, I'm beginning to eperience issues with the limited texture cache of only 512 MB, in that stuff around such a materials-enabled builds has a tendency to bur like crazy. After enduring being relegated to many helpdesk documents, telling me it's probably my router, HTTP-fetch issues, and what not, I was persistent enough to get some reputable builders come over, and witness how, indeed, my 512m3 sky environment (with just 6 basic textures) keeps blurring for them too. At long last we concluded what I had suggested all along: that the materials-enabled homes (potentially tripling your texture memory needs) keep pushing everything else out.

I brought up the matter in several online support groups, where it met less than enthusiasm (to put it mildly). Fine. Like always, though, sticking one's head in the sand rarely makes an issue go away. The matter remains that 512MB is just beginning to be too little. Especially since any half-way decent card has 1.5G to begin with.

So, why not raise the limit to 1.5G? If your card has the room, why not use it?! (Cards with less would simply use less).

The 512MB limit is not hard. And it's viewers limiting themselves. Bao Linden said  (emphasis mine) "This cap is a soft cap. It tells viewer it is good to make the total amount of textures to follow this cap. But if this cap needs to be overflown to make all necessary textures sharp enough, and viewer has resource to overflow the cap, viewer will do it. Of course VIEWER WILL IMMEDIATELY REMOVE UNNEEDED TEXTURES to follow the cap if the situation changes."

Even if it is not possible to raise the limit that high, there should be some way to override the viewer's rather crude way of blurring everything that is fartherst away. Some sort of texture 'persistent' bit.

[Ren Toxx]

---

kiramanell wrote: [...]

 there should be some way to override the viewer's rather crude way of blurring everything that is fartherst away. Some sort of texture 'persistent' bit.

---

Debug settings > “TextureLoadFullRes” = “TRUE”.

But it's not a persistent setting (it'll go back to “FALSE” on next relog), and I've found it makes the viewer a bit too crash-prone, so I only activate it for HQ photography.

[ChinRey]

It is highly unlikely that your problem is caused by cache overload. Even the most powerful computer would probably lag down to a crawl long before the cache gets overloaded by a single environment. Besides, a cache overload should cause textures to turn gray, not blurred.

A more likely explanation is a bug in Project Interesting (see https://jira.secondlife.com/browse/BUG-5978 ). That's easy to check. When the problem occurs, open Develop Menu -> Consoles -> Texture Console and look at the Bias number. If it's stuck at 5, it's the Project Interesting bug. If it is, please add acomment to the Jira with any info you can provide. The case is currently listed as "Needs More Info" and anything we can do to help LL solve it would be greatly appreciated.

Regardless of that issue, I agree with you about cache size. The more files we can store locally, the less load we place on the servers and the network and the less lag we get. Today even the smallest computer tend to have plenty of storage room to spare and it just makes sense to give everybody the option to use that unused resource to improve SL. :-)

You should post a Jira about it. That's where suggestion for new features are supposed to go.

--||-

[kiramanell]

---

Ren Toxx wrote:

---

kiramanell wrote: [...]

 there should be some way to override the viewer's rather crude way of blurring everything that is fartherst away. Some sort of texture 'persistent' bit.

---

Debug settings > “TextureLoadFullRes” = “TRUE”.

But it's not a persistent setting (it'll go back to “FALSE” on next relog), and I've found it makes the viewer a bit too crash-prone, so I only activate it for HQ photography.

---

 

Yeah, I'm familiar with that setting. Granted, it stops blurring (discard = 0), but makes SL unplayable: FPS drops to about 3fps.

Interestingly, bound texture memory is around 900MB that way (nearly twice what the viewer is normally willing to commit). So, basically, the scene is telling SL it needs 900MB, instead of 512.

 

 

 

[kiramanell]

Ok, who deleted my 5th post??! (posting it again)

 

---

ChinRey wrote:

It is highly unlikely that your problem is caused by cache overload. Even the most powerful computer would probably lag down to a crawl long before the cache gets overloaded by a single environment. Besides, a cache overload should cause textures to turn gray, not blurred.

A more likely explanation is a bug in Project Interesting (see

https://jira.secondlife.com/browse/BUG-5978

). That's easy to check. When the problem occurs, open Develop Menu -> Consoles -> Texture Console and look at the Bias number. If it's stuck at 5, it's the Project Interesting bug. If it is, please add acomment to the Jira with any info you can provide. The case is currently listed as "Needs More Info" and anything we can do to help LL solve it would be greatly appreciated.

Regardless of that issue, I agree with you about cache size. The more files we can store locally, the less load we place on the servers and the network and the less lag we get. Today even the smallest computer tend to have plenty of storage room to spare and it just makes sense to give everybody the option to use that unused resource to improve SL. :-)

You should post a Jira about it. That's where suggestion for new features are supposed to go.

---

Interesting post! My Bias seems to be at 0.0, most of the time, and sometimes jumps to 0.25. Highest I've seen it go is a whopping 3.75 (at which time blurring occurs). Nothing stuck at 5.0, though.

Funny thing, though, is that just having set TextureLoadFullRes=TRUE (and relogging to undo it) still had a significant effect on the blurring, in that it suddenly happens far less, Still happens, but it seems to have had an odd revitalizing effect on texture performance as a whole. So, I went to another (busy) sim, to have my cache be filled with new textures; then TP-ed back, but the blurring is still significantly less. Most peculiar.

[Ren Toxx]

I've been using Firestorm for long, and this texture blurring (as related to the bias thing, and usually called “texture trashing”) problem has been a recurring one; almost for every new release it's changed, sometimes for the better, sometimes for the worse; the guys from Firestorm even came up with a few 'patches' of their own to try and solve this (namely, a flag for ATI cards that also made its way to the debug settings), but none has ever been quite definitive. I guess it's mainly because they have to get back to LL's ever-changing rendering code with each new release, and each time it somehow 'breaks' or makes the patch irrelevant.

Which is why I always kept the TextureLoadFullRes setting in my quick preferences panel, to easily toggle it on the moment I needed to do HR capturing, and then off again without even needing to relog.

[kiramanell]

---

Ren Toxx wrote:

I've been using Firestorm for long, and this texture blurring (as related to the bias thing, and usually called 

“texture trashing”

) problem has been a recurring one; almost for every new release it's changed, sometimes for the better, sometimes for the worse; the guys from Firestorm even came up with a few 'patches' of their own to try and solve this (namely, a flag for ATI cards that also made its way to the debug settings), but none has ever been quite definitive. I guess it's mainly because they have to get back to LL's ever-changing rendering code with each new release, and each time it somehow 'breaks' or makes the patch irrelevant.

Which is why I always kept the TextureLoadFullRes setting in my quick preferences panel, to easily toggle it on the moment I needed to do HR capturing, and then off again without even needing to relog.

---

Well, in all fairness to the FS team (who were very unwilling to discuss the matter, though), the official Linden viewer suffers from this just as much.

Under normal circumstances, using a thing like TextureLoadFullRes is like messing with a process scheduler: rarely a good idea (even when ppl think it is). However, in this case, always blurring the farthest thing off isn't always a good idea either (especially with things like sky environments that are, by their very nature, meant to be persistent). So, I really wouldn't mind seeing a 'Persistent' flag on the texture options (like an individual TextureLoadFullRes=TRUE for the particular facing/texture of your choice in question).

Still, in my stand-alone skybox (with nothing else in 512m3 range around it), Bias shouldn't have to swagger from 0.0 to (and inexplicable) > 4.0, when I'm not even moving. It's like textures have a ridiculously low TTL. When nothing new needs to be loaded, texture cache shouldn't go haywire all on its own (as if an entire new scene is being loaded).

 

 

 

[kiramanell]

I figured it might probably be a good idea to illustrate the effect with a small video (see below). At some point you can even see the viewer (Firestorm) go into some sort of loading-loop.

As outlined above, this only happens with certain scenes (in this case: a hefty, materials-enabled home), and not in general. Clearly the viewer is simply running out of texture memory.

With the advent of materials (like I said, potentiallly tripling your texture memory needs) I was really hoping this doesn't get ignored, and that, at some point, the powers that be will increase viewer texture memory to accomodate for materials.

And yes, I like high-graphics settings. To paraphrase Madonna: I'm a materials girl in a materials world. And I'm not throttling down on those (especially since my video-card offers 3x the amount of texture memory SL is willing to use).

 

[Rolig Loon]

---

kiramanell wrote:

[ .... ] Clearly the viewer is simply running out of texture memory.[ ... ]

---

Or your router is being swamped by a massive flow of data.  Take a good look at http://wiki.phoenixviewer.com/http_fetching_issues

[kiramanell]

---

Rolig Loon wrote:

---

kiramanell wrote:

[ .... ] Clearly the viewer is simply running out of texture memory.[ ... ]

---

Or your router is being swamped by a massive flow of data.  Take a good look at

http://wiki.phoenixviewer.com/http_fetching_issues

---

Or you could look at my first post in this thread, and see that others have visited my sim too, and noticed the same blurring.

[Rolig Loon]

I did.  You may not be the only one with the issue.  :smileywink:

[kiramanell]

---

Rolig Loon wrote:

I did.  You may not be the only one with the issue.  :smileywink:

---

Then look closer at my video, please. You can clearly see Bias go from ca. 3.0 - 5.0, That is NOT a HTTP fetch issue, but irrefutable proof of texture memory shortage (cuz that's what the Bias is: it increases when not enough texture memory is available to keep all textures at full resolution).

Also, as you can tell from the texture cache menu, you can witness textures getting (re)loaded like crazy, even when I'm virtually standing still. There's no good reason for that (there's nothing present in a 512m3 radius either), unless it constantly discards textures because of texture memory shortage.

 

Like your tagline, I'm not as dumb as I look. So, not specifically aimed at you, but please, please, no more dismissals or just blaming it on my router or something.

[Rolig Loon]

No dismissal was intended.  It was a helpful suggestion, which you are free to ignore if you think that it doesn't apply to your situation.  No need to feel offended by it.  Good luck solving your problem.

[arton Rotaru]

---

kiramanell wrote:

---

Like your tagline, I'm not as dumb as I look.

So, not specifically aimed at you, but please, please, no more dismissals or just blaming it on my router or something.

---

Could still blame it on your SL environment, which, perhaps, doesn't suit the current limits of the SL viewer. :matte-motes-tongue:

Just out of curiosity, what is your draw distance, and your RenderVolumeLODFactor in that video?

[kiramanell]

---

arton Rotaru wrote:

---

kiramanell wrote:

---

Like your tagline, I'm not as dumb as I look.

So, not specifically aimed at you, but please, please, no more dismissals or just blaming it on my router or something.

---

Could still blame it on your SL environment, which, perhaps, doesn't suit the current limits of the SL viewer. :matte-motes-tongue:

Just out of curiosity, what is your draw distance, and your RenderVolumeLODFactor in that video?

---

Precisely: it seems my SL environment doesn't suit the current limits of the SL viewer. I 'blame' the potenttial texture tripling of materials (until a better explanation comes along).

My RenderVolumeLODFactor is at 4 (shouldn't affect blurring of textures on regular prims at all), My dd is set at 512m; but even at 256m I'm getting the exact same issue (as expected: there's simply nothing in a 512m3 radius around the home, besides the environment, to render anyway).

[arton Rotaru]

I just wonder how such an environment is looking like? In that video there are only a couple of objects in view, which shouldn't result in such an amount of texture data.

[kiramanell]

---

arton Rotaru wrote:

I just wonder how such an environment is looking like? In that video there are only a couple of objects in view, which shouldn't result in such an amount of texture data.

---

 

The environment is the simplest you can imagine: 6 hollowed/cut boxes, with a texture on each of the 6 inner facings,

Indeed, there's a wicked amount of texture data going on -- for no apparent reason, far as I'm concerned (once the scene is loaded, no need to keep reloading things). I did blank all textures on the home and furniture, btw (just for test); and sure enough no blurring of the environment takes place any more. Kinda makes sense, of course, as only 44MB texture memory seemed occupied at the time, LOL. Full home, however, has texture memory tilt the 512MB limit, and often over it. And the latter is, of course, what's causing the blurs and reloads: the viewer just won't give it the memory it needs.

Tried this with a 'mini' 64m3 environment too; same deal: it will blur too.

You're free to inspect it for yourself, btw, if you want.

[arton Rotaru]

Yep, I would like to check this out by myself, if you don't mind. :matte-motes-nerdy:

[kiramanell]

---

arton Rotaru wrote:

Yep, I would like to check this out by myself, if you don't mind. :matte-motes-nerdy:

---

^^ And he just did.

I hope he doesn't mind me saying, but he confirmed that this is, indeed, a texture memory issue. He noticed some big 1024 textures on a table and some other things. And one could question the validity of using those for such pieces (they're non-transfer, so I couldn't export textures to make em low-res, even if I wanted to). Still, with the materials-enabled home, the viewer simply can't handle the load.

His Bias was consistently lower for him than for me, but he was on a different viewer (experimental Linden?), so it may be I had still higher settings somehow. At any rate, he observed the issue too.

At some point LL will simply have to acknowledge that the potential tripling of your texture memory needs, that comes with materials, means that 512MB simply isn't cutting it any more.

[arton Rotaru]

Right, there is a high amount of texture data going on. I'm not sure where the massive load is coming from actually. Maybe there are a couple of very bad objects around. Some which have plenty of 1024² textures on them? Idk. Even when I zoomed onto a single item, with just the object, and the sky in view, the "Bound" texture load stayed fairly high, at 250 MB. If I try the same in may own skydome, the Bound number decreases to something like 20 MB immediatly. So something strange is going on there perhaps.

Though, I didn't had the unsharping/sharpening issue like shown in the video. Once my cam stood still, there wasn't any unloading/loading going on in the texture console. Of course, moving my cam around, I had to reload the highest texture LODs behind me again.

For me the place worked kind off. Even if my Bias maxed out at 3.5 at times.

The Viewer I used is Second Life MemPlugs RC, which adresses memory leaks in the viewer.

[kiramanell]

---

arton Rotaru wrote:

Right, there is a high amount of texture data going on. I'm not sure where the massive load is coming from actually. Maybe there are a couple of very bad objects around. Some which have plenty of 1024² textures on them? Idk. Even when I zoomed onto a single item, with just the object, and the sky in view, the "Bound" texture load stayed fairly high, at 250 MB. If I try the same in may own skydome, the Bound number decreases to something like 20 MB immediatly. So something strange is going on there perhaps.

Though, I didn't had the unsharping/sharpening issue like shown in the video. Once my cam stood still, there wasn't any unloading/loading going on in the texture console. Of course, moving my cam around, I had to reload the highest texture LODs behind me again.

For me the place worked kind off. Even if my Bias maxed out at 3.5 at times.

The Viewer I used is

Second Life MemPlugs RC,

which adresses memory leaks in the viewer.

---

The massive load is coming primarily from the home: blank out the home (like I did above), and the blurring stops. This home is from a very reputable builder, btw. So I don't think it's really a 'bad' object so much as a 'fancy' object: the building is simply high-res with materials. And my furniture is high-quality too.

Bias, for me, becomes problematic when it starts getting way over 4 (which it does very often for me in this home). At 3.5, like yours, some blurring still occurs, but far less obnoxious.

I'll try out that other viewer, but, in all honestly, I don't think a generic memory leak fix is gonna take care of my texture memory shortage.

[kiramanell]

Okay, who keeps deleting my last post?! (In which I point to the Jira I filed about it), STOP DOING THAT!

[arton Rotaru]

---

kiramanell wrote:

I'll try out that other viewer, but, in all honestly, I don't think a generic memory leak fix is gonna take care of my texture memory shortage.

---

Perhaps not. However, it would be my recommended viewer anyway, because it's the latest in viewer development which addresses performance.

[Rolig Loon]

Only a moderator can remove a post.  Nobody else has that power.  Also remember that the forum guidelines say

We prohibit abuse of our moderation process, including the following:

• Posts that discuss or re-post material that has been removed or locked by a moderator
• Posts questioning a moderator’s decision

 

[kiramanell]

---

Rolig Loon wrote:

Only a moderator can remove a post.  Nobody else has that power.  Also remember that the

forum guidelines

say

We prohibit abuse of our moderation process, including the following:

• Posts that discuss or re-post material that has been removed or locked by a moderator
• Posts questioning a moderator’s decision

---

 

Then it would behoove a moderator to have the courtesy to at least inform me that a post has been removed (and wasn't just eaten by the server). Although I can't for the life of me imagine why someone would remove a simple post with a link to a Jira in it.

Also, no offense, but you are not a moderator. So, please don't tell me I can't question a moderator's decision when it's entirely unclear (to you as well) that a moderator was even involved to begin with