[sldev] How Far For Security?
Callum Lerwick
seg at haxxed.com
Sat Jun 21 16:33:14 PDT 2008
On Sat, Jun 21, 2008 at 3:14 PM, Argent Stonecutter <secret.argent at gmail.com>
wrote:
> On 2008-06-21, at 01:12, Callum Lerwick wrote:
>
>> I may be late to the party here, but mark my words, if the cache is
>> changed to anything other than plain, complete files in a standard file
>> format, it will be the final nail in the coffin for my already tenuous faith
>> in Linden Lab's collective engineering sense.
>>
>
> Even if a non-standard format that's a serialization of the internal
> structures is faster and more efficient?
Until you have to change the internal structures and suddenly your cache
needs to be wiped and re-filled. Which would defeat the purpose of the
cache. To avoid this you have to abstract your internal structures from the
on disk format, and if you're going to do that, you might as well use a
pre-existing standard. There's plenty to choose from already. And as noted,
there's already TGA reading code in the viewer.
There's no solid engineering reason to go with a standard file format for a
> *cache*.
>
Seriously, have we not been bitten by lack of engineering foresight in SL
infrastructure enough as it is?
Why do I even have to explain this?
Also note, if we're going to do the uncompressed cache thing, XORing the
>> file will eliminate the possibility of zero-copy DMAing of the texture
>> directly from disk into VRAM. XOR is still more overhead than having the
>> texture not hit the processor at all.\
>>
>
> The Amiga did MFM decoding on the blitter, and that had a fraction of the
> versatility of any modern GPU, there's no reason that the GPU can't do any
> operations needed to remove obfuscation.
Except that programmable cards only do FP, not integer/binary operations
like XOR. And shaderless cards are still in wide use, not to mention bugs in
shader implementations are still widespread, and the open source r300
drivers for one still don't support shaders.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080621/f89d526e/attachment-0001.htm
More information about the SLDev
mailing list