Gabryel Nyoki Posted July 12, 2017 Share Posted July 12, 2017 Hello, Is it normal that the viewer keeps refreshing/rebaking textures randomly non stop? I can't even take pics without having stuff blurry Thanks, Gab Link to comment Share on other sites More sharing options...
LittleMe Jewell Posted July 12, 2017 Share Posted July 12, 2017 If your texture cache is full then texture thrashing can occur, and that will cause things to continually blur and sharpen. Which viewer are you using? The SL viewer limits the texture cache to 512 MB, so it can get full quickly if you are somewhere with lots of large textures. 1 Link to comment Share on other sites More sharing options...
Gabryel Nyoki Posted July 13, 2017 Author Share Posted July 13, 2017 Hi, yes and Firestorm is not much bigger than that. Notwithstanding, Official Viewer should load textures yes? Makes no sense that I can't make a snapshot without blurry stuff? There has to be some setting... Thank you Link to comment Share on other sites More sharing options...
LittleMe Jewell Posted July 13, 2017 Share Posted July 13, 2017 I'm using the 64-bit Firestorm and since my graphics card can support it, my texture cache is 2048 MB. That is a big difference if I happen to be in an area with a lot of intense textures and I want my graphics settings turned up. The Official viewer can load textures, but you are still limited by the cache size. If you happen to be trying to pull in more than 512 MB with all of the textures around you, then they will start swapping in and out, causing the blurring. As to what settings to change: Start with turning down your draw distance to no more than you really need for you scene, 64-128m (the higher the distance, the more the viewer will try to rez, which adds to that texture load). Keep the maximum complexity set low so that you are not rendering anyone really complex (default is really high). Also, I'd recommend posting you viewer and computer info -- click Help / About Secondlife on the viewer menu; copy and paste the results here. Link to comment Share on other sites More sharing options...
Nova Convair Posted July 13, 2017 Share Posted July 13, 2017 Texture thrashing doesn't exist for me - since Firestorm (and other TPV's) allow to use 2048 MB of texture memory. It's simple math: 2048 MB here and 512 MB for the LL viewer. That's one big advantage of 64 bit over 32 bit viewers - you can use alot more memory. If LL builds that into their shiny new 64 bit viewer - the LL viewer will become useable again. If not it's good enough for a laugh then. To use that feature you have to have the memory of course. Min 3 GB on the graphics card (not sure if that's enough) and at least 8 GB main memory. Link to comment Share on other sites More sharing options...
Ayesha Askham Posted July 13, 2017 Share Posted July 13, 2017 Seriously? LL have issued the 64 bit viewer with a 512MB texture memory limit?? After all the testing we did??? That beggars belief! Link to comment Share on other sites More sharing options...
LittleMe Jewell Posted July 13, 2017 Share Posted July 13, 2017 (edited) 13 minutes ago, Ayesha Askham said: Seriously? LL have issued the 64 bit viewer with a 512MB texture memory limit?? After all the testing we did??? That beggars belief! What Nova was saying was IF LL DID allow for larger cache in their 64-bit then the viewer will be considered usable again. She doesn't know what the cache limit of that viewer is -- it has not been officially released yet. It can be pulled and installed, if you want to try it. http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers The current LL viewer is 32-bit and limits the texture cache to 512 mb. Edited July 13, 2017 by LittleMe Jewell Link to comment Share on other sites More sharing options...
Ayesha Askham Posted July 13, 2017 Share Posted July 13, 2017 (edited) OK I got the wrong message and shouted before I heard the truth. Simply I found it inconceivable that the Alex-Ivy test viewer should have the extended VRAM and an issued version should not. I attributed unreasonable idiocy to LL for no good reason.. My bad, as they say. I hope the 64 bit LL viewer will be released soon. It is sorely needed. Edited July 13, 2017 by Ayesha Askham Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted July 14, 2017 Share Posted July 14, 2017 8 hours ago, Ayesha Askham said: Seriously? LL have issued the 64 bit viewer with a 512MB texture memory limit?? After all the testing we did??? That beggars belief! The LL 64bit currently has VRAM limited to 512 MB but as far as I'm aware LL are working on raising the VRAM limit. Allowing a higher VRAM in the viewer safely is not as easy as you may think. It took Firestorm quite a while to get that feature working well. The problem is you can't just allow any system to raise the VRAM limit or the viewer will be VERY unstable on unsuitable systems - out of memory crashes & poor performance when the texture memory is higher then the system can handle. It really isn't just a case of raising the limit universally & hoping for the best. Link to comment Share on other sites More sharing options...
LittleMe Jewell Posted July 14, 2017 Share Posted July 14, 2017 3 hours ago, Ayesha Askham said: OK I got the wrong message and shouted before I heard the truth. Simply I found it inconceivable that the Alex-Ivy test viewer should have the extended VRAM and an issued version should not. I attributed unreasonable idiocy to LL for no good reason.. My bad, as they say. I hope the 64 bit LL viewer will be released soon. It is sorely needed. Nope - you should be shouting. My initial comments in this thread were all about the currently released SL viewer - I missed the OP info about releae 5.1.0.507006. However, I just pulled the 64-bit version that specific release, which is the Alex_Ivy project, and the texture cache is STILL limited to 512 mb. I am totally speechless.. Link to comment Share on other sites More sharing options...
LittleMe Jewell Posted July 14, 2017 Share Posted July 14, 2017 1 minute ago, Whirly Fizzle said: It took Firestorm quite a while to get that feature working well. So, LL just needs to pay the Firestorm folks to fix the LL viewer. Link to comment Share on other sites More sharing options...
Phil Deakins Posted July 14, 2017 Share Posted July 14, 2017 (edited) 9 hours ago, LittleMe Jewell said: So, LL just needs to pay the Firestorm folks to fix the LL viewer. Nope. The LL viewer isn't broken, so it doesn't need to be fixed. Improved, perhaps, but not fixed. Edited July 14, 2017 by Phil Deakins Link to comment Share on other sites More sharing options...
LittleMe Jewell Posted July 14, 2017 Share Posted July 14, 2017 3 hours ago, Phil Deakins said: Nope. The LL viewer isn't broken, so it doesn't need to be fixed. Improved, perhaps, but not fixed. Guess I should have qualified that statement to say "fix that VRAM limit issue" - and yes, I see a VRAM limit of 512 MB on a 64-bit machine as an issue that need to be fixed. Link to comment Share on other sites More sharing options...
Phil Deakins Posted July 14, 2017 Share Posted July 14, 2017 Just out of interest... A 64 bit machine simply means that it has a 64 bit address bus, data bus - or both. I think the address bus is more common. It means that it can access twice as much inline memory in a single access than a 32 bit address bus. Example:- a 4 bit address bus can read a byte of memory in a line of up to 16 bytes of memory in one go. If there are 32 bytes of memory, then it would need some manipulating to read a byte from the upper 16, so it can't be done in one go. So a 64 bit address bus only means that memory accesses are fractionally quicker if the machine has more memory than a 32 bit bus can access in one go. It has nothing to do with how much memory the computer has. It's only about teeny weeny bits of speed. So the discussion as to whether or not a 64 bit computer has more than 512M of texture cache isn't really the point, imo. Link to comment Share on other sites More sharing options...
Ayesha Askham Posted July 14, 2017 Share Posted July 14, 2017 I think were are missing the point here. The 64 bit viewer IS going to be useful for those users whose OS operate on a 64 bit bus, but only marginally. The issue of extended VRAM is another matter entirely. Most modern GPUs have over 1GB of VRAM. Many have over 2GB. It is THAT which will make the huge difference to most. Extending the VRAM addressed by the viewer vastly improves the viewer's ability to process and render complex scenes quickly. That much I know from personal experience using both 32 and 64 bit versions of Firestorm and a test build of the LL 64 bit (which did have up to 2048MB texture memory option, Whirly) against the standard default viewer. So let's be clear: a 64bit LL viewer with only 512B addressable VRAM will not give any noticeable improvement, but one that can use more VRAM most assuredly will. Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted July 14, 2017 Share Posted July 14, 2017 1 hour ago, Ayesha Askham said: So let's be clear: a 64bit LL viewer with only 512B addressable VRAM will not give any noticeable improvement... I disagree with that. Standard out of memory crashes are pretty much unknown on 64bit viewers. 32bit viewers suffer frequently from out of memory crashes. A 32bit viewer running on a 32bit system can use a maximum of 2GB memory before an out of memory crash will happen. A 32bit viewer running on a 64bit system can use a maximum of 4GB memory. The memory a 64bit viewer can use is "unlimited", dependent on the amount of memory the system has of course. 64bit viewers are known to have half the crash rate of 32bit, pretty much all because the out of memory crashes are eliminated. Link to comment Share on other sites More sharing options...
Phil Deakins Posted July 14, 2017 Share Posted July 14, 2017 (edited) The point is that it is not the width off the address bus and/or data bus that makes a relevant difference. 32 bit and 64 bit buses have only a slight speed difference. It's other parts of the computer system that dictate whether or not crashes occur. If a 32 bit system, running a 32 bit viewer has a massive amount of memory, then there won't be a problem as long as the texture cache can be set to a suitable amount. On the other hand, a 64 bit system, running a 64 bit viewer will have problems if the system doesn't have a large amount of memory. It's not the 'bits' that matter. That's a red herring. It's the amount of memory, and whether or not a suitable size of texture cache, can be set that matters. Edited July 14, 2017 by Phil Deakins Link to comment Share on other sites More sharing options...
Nova Convair Posted July 14, 2017 Share Posted July 14, 2017 19 minutes ago, Phil Deakins said: If a 32 bit system, running a 32 bit viewer has a massive amount of memory, then there won't be a problem as long as the texture cache can be set to a suitable amount. On the other hand, a 64 bit system, running a 64 bit viewer will have problems if the system doesn't have a large amount of memory. 1st of all you need to have the memory. If you have 4GB or less you don't even need to read this thread. If you have the memory the important thing is how much of that you can adress. And that's the point where 32 bit systems are limited. Only 64 bit systems can adress all the memory and that's why a 64bit viewer on a 64bit operating system is far superior over 32bit stuff. It has nothing to do with speed. A 64bit application can be much faster than a 32bit due to using 64bit code but only in very few cases - so that's pretty irrelevant. The viewer will have no noticeable difference in speed. Now that this is settled (if you don't believe it - none of my problems ) - the next question is how you use that amount of memory: - you don't crash on busy places because you don't run out of memory - you don't crash because the memory waste - caused by bugs in the viewer - doesn't hit you (you have enough reserves to waste memory) - you don't encounter texture thrashing - If your viewer allows more texture memory and your graphics card has enough memory of course. If the slider for texture memory is pulled to the max on a system that is not capable of handling it - there will be crashes or serious performance loss - followed by howling in the forums I assume. So I can imagine that LL will avoid a quick shot. 2 Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted July 14, 2017 Share Posted July 14, 2017 2 hours ago, Phil Deakins said: If a 32 bit system, running a 32 bit viewer has a massive amount of memory, then there won't be a problem as long as the texture cache can be set to a suitable amount. There will be a problem. A 32bit viewer on a 32bit system can only use 2 gig total memory before it crashes from out of memory - this is a 32bit restriction, nothing specific to SL viewers. If the texture memory is set to 512MB, 512MB memory is reserved for textures & that leaves only ~1.5 gig of memory for everything else - the viewer will crash very easily in busy locations from out of memory. If a 32bit viewer allowed texture memory to be set higher then 512MB then the out of memory crashes would be even more likely to occur because there is even less memory left for the viewer to use. Allowing the texture memory to be raised above 512MB on any 32bit viewer is a terrible idea. Even on a 64bit system, where a 32bit viewer can use a total of 4 gig memory, because the viewer is built with LAA (Large Address Aware), allowing the texture memory to be raised above 512MB will raise the crash rate substantially - there is just not enough total memory to spare on a 32bit viewer. 2 hours ago, Phil Deakins said: On the other hand, a 64 bit system, running a 64 bit viewer will have problems if the system doesn't have a large amount of memory. For Firestorm, we recommend that if a 64bit system does not have at least 4 gig of RAM then it's best to use the 32bit viewer. 1 Link to comment Share on other sites More sharing options...
Phil Deakins Posted July 14, 2017 Share Posted July 14, 2017 (edited) 2 hours ago, Nova Convair said: If you have the memory the important thing is how much of that you can adress. And that's the point where 32 bit systems are limited. Only 64 bit systems can adress all the memory and that's why a 64bit viewer on a 64bit operating system is far superior over 32bit stuff. It has nothing to do with speed. Au contrair. It has everything to do with speed. So much so that you yourself actually explained why - like I did only in more detail If you read my earlier post, you'll understand why a 64 bit address bus is quicker than a 32 bit one. Perhaps you're thinking about speed in a different area. I'm talking about the speed getting data from memory into the CPU when there is more RAM than a 32 bit address bus can address. If a programme is written so that it can't get at the memory that has an address higher than a 32 bus can address, then it has to swap chunks of memory to get at it. Maybe they don't do that these days because they don't write machine code any more, but when I wrote multi-user games on a machine that had only an 8 bit address bus, swapping was the method used. It was quick though - not like swapping to hard drive. Nevertheless, talking about 32 bits and 64 bits is really a red herring. If a programme is written that can get at the memory that is out of its address range, then it's just a matter of speed, and the difference in speed is tiny. That's what I was saying. If they don't swap memory any more, then alright, I'll withdraw my thought. Maybe I'm just too out of date, programming-wise Edited July 14, 2017 by Phil Deakins Link to comment Share on other sites More sharing options...
Phil Deakins Posted July 14, 2017 Share Posted July 14, 2017 (edited) Oops. I made a mistake. Edited July 14, 2017 by Phil Deakins Link to comment Share on other sites More sharing options...
Ayesha Askham Posted July 14, 2017 Share Posted July 14, 2017 Now this is getting silly. OK Whirly, I forgot about the memory-use advantages of the 64 bit. I ought to have remembered that we made use of it on FS for quite a while and I did indeed see out of memory crashes on 32 bit viewers. Phil, I am puzzled. 512MB is 0.5GB surely. That is a heck of a big drop in a rather small ocean. Link to comment Share on other sites More sharing options...
Phil Deakins Posted July 14, 2017 Share Posted July 14, 2017 33 minutes ago, Whirly Fizzle said: There will be a problem. A 32bit viewer on a 32bit system can only use 2 gig total memory before it crashes from out of memory - this is a 32bit restriction, nothing specific to SL viewers. Such limits didn't used to be a restriction. We used to access much more memory than the 8 bit address bus could address. We swapped chunks of memory back then. Isn't that done any more? Link to comment Share on other sites More sharing options...
Phil Deakins Posted July 14, 2017 Share Posted July 14, 2017 1 minute ago, Ayesha Askham said: Phil, I am puzzled. 512MB is 0.5GB surely. That is a heck of a big drop in a rather small ocean. Don't remind me. I made a blunder. It's late in evening here and my brain failed to work properly Link to comment Share on other sites More sharing options...
Gabryel Nyoki Posted July 15, 2017 Author Share Posted July 15, 2017 Thank you for answers guys, I gifured that it was my Belleza HUD which has mesh textures, that is so heavy that builds up the 521MB texture. I hope they increase this since I use a GTX with 6Gb Link to comment Share on other sites More sharing options...
Facebook
Instagram
Twitter
YouTube
Flickr
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now