On Fri, 16 Dec 2016 11:14:59 -0800, Richard Nelson wrote:
> FWIW, those particular units types were introduced as part of the LLTrace
> metrics update and found several cases where the incorrect units were
> being recorded, resulting in skewed/invalid metrics. The point is not
> that it is
FWIW, those particular units types were introduced as part of the LLTrace
metrics update and found several cases where the incorrect units were
being recorded, resulting in skewed/invalid metrics. The point is not
that it is hard to multiply by a constant to do unit conversion...it is
that
On Fri, 16 Dec 2016 10:07:45 -0500, Monty Brandenberg wrote:
> On 12/16/2016 4:16 AM, Henri Beauchamp wrote:
>
> > I'd say that the demonstration of how templates can actually
> > harm the maintainability of the code is done...
>
> Hahaha, that is a permanent on-going debate.
I said *can harm*,
On 12/16/2016 4:16 AM, Henri Beauchamp wrote:
> I'd say that the demonstration of how templates can actually
> harm the maintainability of the code is done...
Hahaha, that is a permanent on-going debate.
m
___
Policies and (un)subscribe information a
On Fri, 16 Dec 2016 09:44:51 +0100, Henri Beauchamp wrote:
> my viewer is therefore unafffected by that bug...
In fact, I had a doubt and checked: it was affected, but the fix took
me exactly 3 minutes to perform (4 static variables in LLImageGL and
LLViewerTexture that were S32 integers and that
On Thu, 15 Dec 2016 11:13:35 -0800, Callum Prentice (Callum) wrote:
> https://jira.secondlife.com/browse/BUG-41029
>
> .../...
>
> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined
> indirectly here:
>
> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33a
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
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 abou
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
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
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 3
11 matches
Mail list logo