[sldev] Issues with TextureBuffer size

[Callum Lerwick]

On Sat, 2007-05-19 at 22:56 +0200, Nicholaz Beresford wrote:
> 
> > > There's also an issue with sMaxTotalTexture being of type S32
> > > which will cause problems with systems with >2GB memory
> > > (this is not yet fully addressed in this patch)
> > >     
> > This may be of interest?
> > https://jira.secondlife.com/browse/VWR-207
> >   
> Thanks ... yes, this is the same.  I'll try to address that with my
> patch also.

We're going to have to bite the bullet on this sooner or later. As we're
entering the era of consumer 64bit, the datatype used in memory size
calculations needs to be increased. I see two options, both of which
could be done:

Use size_t. This is kind of what it's meant for, isn't it? This would
have the possible advantage of automatically being 64bit on 64bit
platforms, and 32bit on 32bit platforms.

Do we really need byte accuracy? Perhaps the unit could change to
measuring kilobytes instead of bytes.

Also, in any event the platform code that detects the memory size really
ought to just cap the value in the event of overflow. Think of an i386
machine with 8gb RAM (PAE). It would be better to misreport it as 2gb
RAM than to overflow and cause badness. With PAE a single process can't
access all the RAM anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070521/c4ce4551/attachment.pgp