Re:Reverse Engineering the Comtech AHA363 PCIe Gzip Accelera...
by battery423 on Wednesday June 24, 2020 @04:15AM
(#23625458)
I do have seen issues on my machines i would highly put in the direction of "nvm got shitty fast really quick and something inbetween is weird, we need to do something".
My feeling is, that what Sony is now doing, goes in that direction.
I'm highly curious and hopefull.
I will read your posted blog, looks interesting. Lets see what will arrive in the industry at the end of the day.
Re:Reverse Engineering the Comtech AHA363 PCIe Gzip Accelera...
by battery423 on Wednesday June 24, 2020 @04:27AM
(#23625521)
When i look at his data, its capped and the additional PC transfer speed of over 512mb/sec vs hitting the speed limit much sooner, does show that something is missing.
Re:Reverse Engineering the Comtech AHA363 PCIe Gzip Accelera...
by rasz on Wednesday June 24, 2020 @06:02AM
(#23626131)
Diminishing returns. Cap is most likely caused by the graphic engine fixed costs, at some point you cant use more speed no matter what without rewrite (initialization, deserialization etc).
> IO chip and extra architecture for decompressing textures
you dont want uncompressed textures in your GPU memory, compressing DXT compressed textures is not idea to say the least, you can count on 30-50% compression ratio, not the marketing 2x peak number Sony was throwing around
>would use all CPU cores
is marketing exaggeration, LZ4 decompression can achieve ~3GB/s per core. How it is today: https://www.jonolick.com/home/oodle-and-ue4-loading-time