[opensource-dev] Question about BUG-41029 and 64 bit usage

[Niran]

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) <callum at 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.uchi at 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) <callum at 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/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161216/d47601a8/attachment-0001.htm