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

2016-12-15 Thread Callum Prentice (Callum) 
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 
___
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

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

2016-12-15 Thread Niran 
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) :

> 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 
>
> ___
> 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

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

2016-12-15 Thread Callum Prentice (Callum) 
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 
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) 
> :
>
>> 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 
>>
>> ___
>> 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 
___
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

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

2016-12-15 Thread 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) :

> 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 
> 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) > >:
>>
>>> 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 
>>>
>>> ___
>>> 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 
>
___
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

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

2016-12-15 Thread Cinder Roxley 
Mine has 6GB and was relatively inexpensive ($211 USD)

As far as the viewer, I think the best way to go would be to bite the bullet 
and rework those to use size_t. 
 
 
-- 
Cinder Roxley
Sent with Airmail
 

On December 15, 2016 at 7:03:58 PM, Callum Prentice (Callum) 
(cal...@lindenlab.com  ) wrote:

 
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 mailto: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) mailto:cal...@lindenlab.com> >:
https://jira.secondlife.com/browse/BUG-41029

I'm taking a look at https://jira.secondlife.com/browse/BUG-41029and 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  


___
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  


___
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