News for hackers. Stuff that matters.
Re:Reverse Engineering the Comtech AHA363 PCIe Gzip Accelera... by rasz on Tuesday June 23, 2020 @08:59AM (#23613265)
PC SSD drives started out with buildin compression. This is why most test software has separate "incompressible data" graphs. Its usually something you actually dont want, akin to fake streamer tape capacities/speeds assuming 2x compression.

> 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

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).