They do, the new ones at least, up to 8gb and possibly more already. But then i think using more than 4gb is currently useless anyway, the Viewer can hardly handle 1992mb (currently tested) for both Texture and Scene memory coming up to a total of roughly 4gb. On top of that if you're talking about RAM usage, it shouldn't be a problem either, the Viewer memory display is obsolete anyway and always was kinda wrong and/or lining up with what the task manager was showing. If you want to check memory usage you would naturally use the task manager anyway. I fear though that it might be used somewhere and could potentially lead to faulty memory handling behavior, like when a feature asks for the memory usage to start preventive measures (like we had long ago with the auto close after 30 seconds when memory usage went too high). Other than that i see no reason to fix a wrong memory display as it is just that, a display, information no one except maybe skilled render coders are ever going to use but then again i see no reason not to fix it. If you get the chance to do it, you should go ahead and fix it, as side project maybe so it doesn't interfere with your current projects.
2016-12-16 2:03 GMT+01:00 Callum Prentice (Callum) <cal...@lindenlab.com>: > Yep - I saw a lot of memory related texture references too - I don't know > if cards these days have more than 4GB of video memory - definitely a > possibility soon if not already. > > On Thu, Dec 15, 2016 at 5:01 PM, Niran <desmoulins.u...@googlemail.com> > wrote: > >> Funny, i just so happened to stumble across this a few days ago when i >> had this mindblowing realization that this might be the cause for the >> Viewer not properly reporting VRAM over 4gb but i don't happen to have a >> 4+gb VRAM GPU so i wouldn't be able to test anything i do and ultimately >> dropped the idea of touching it for now. >> >> 2016-12-15 20:13 GMT+01:00 Callum Prentice (Callum) <cal...@lindenlab.com >> >: >> >>> https://jira.secondlife.com/browse/BUG-41029 >>> >>> I'm taking a look at https://jira.secondlife.com/browse/BUG-41029 and >>> whilst it seems straightforward, it seems to be unraveling into something >>> that touches dozens of files and I wondered if someone had done this work >>> already. >>> >>> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) >>> defined indirectly here: >>> >>> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9 >>> c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at= >>> default&fileviewer=file-view-default#llunittype.h-824 >>> >>> that are used to count memory sizes/usage/difference etc. I think we >>> can convert them to their U64 equivalents for all viewers. >>> >>> Nat points out, rewriting this code using size_t as a return type would >>> make more sense but that seems like it would involve more invasive code >>> changes including changes in fundamental LL headers. >>> >>> What does the collective wisdom say? >>> >>> -- >>> >>> CALLUM PRENTICE | Software Engineer >>> >>> LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > > -- > > CALLUM PRENTICE | Software Engineer > > LINDEN LAB | Create Virtual Experiences <http://www.lindenlab.com/> >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
