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/ > 9270caf3d4324f9c1c33aa158f80e0fe84036a48/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
