AMD Releases Brotli-G For GPU-Accelerated Brotli Compression

[microcode]

That converter is called Clang. Just fetch the DX compiler and compile it. Or wait until upstreaming of the HLSL front-end is finished (it's pending) and upstream Clang will do the trick, won't need MS's fork anymore.

Glslang/shaderc handles HLSL as well, and outputs SPIR-V.

[bug77]

I thought brotli was designed to be easy on hardware (being able to run on phones and such). What am I missing here? Why does it need to run on GPUs now?

[ktecho]

I thought brotli was designed to be easy on hardware (being able to run on phones and such). What am I missing here? Why does it need to run on GPUs now?

Wow... English is not my primary language, so I skipped that part where they say that using a GPU is needed for brotli...

Could you point me to the specific text where they say that?

[andrei_me]

I thought brotli was designed to be easy on hardware (being able to run on phones and such). What am I missing here? Why does it need to run on GPUs now?

I believe it doesn't need but it is an option if you need that compressed data on vRAM, you decompress there and then you don't need to transfer it from system memory to vRAM

[bug77]

I believe it doesn't need but it is an option if you need that compressed data on vRAM, you decompress there and then you don't need to transfer it from system memory to vRAM

What would you keep in VRAM that would benefit from brotli? Brotli is good with small files, it sucks with something as large as a texture. Maybe this is aimed at some sort of compute scenario?

[Artim]

I thought brotli was designed to be easy on hardware (being able to run on phones and such). What am I missing here? Why does it need to run on GPUs now?

Not a contradiction. Just because it's relatively easy on hardware doesn't mean that Data Centers, CDNs etc constantly compressing many files per second can't profit from parallelization. For all I understand, it's only supposed to be that much faster because it can do more in parallel. The question is only, how much potential there is for parallelization compressing one file. Because for all I understand compression of web traffic, you don't necessarily compress the whole file, but split it into chunks and compress them. If I was wrong, that would explain things, when you need to compress larger files.

[bug77]

Not a contradiction. Just because it's relatively easy on hardware doesn't mean that Data Centers, CDNs etc constantly compressing many files per second can't profit from parallelization. For all I understand, it's only supposed to be that much faster because it can do more in parallel. The question is only, how much potential there is for parallelization compressing one file. Because for all I understand compression of web traffic, you don't necessarily compress the whole file, but split it into chunks and compress them. If I was wrong, that would explain things, when you need to compress larger files.

Again, brotli is meant for smaller files. It doesn't do well with bigger ones (its dictionary is rather small).

[Artim]

Just because it's meant for that doesn't mean it can't be used otherwise. Also, GPUs do have more cores than CPUs. So if that helps processing more files in parallel, that could already be enough of a benefit for some.

[cj.wijtmans]

I like Brotli in dragonball.

[bug77]

Just because it's meant for that doesn't mean it can't be used otherwise. Also, GPUs do have more cores than CPUs. So if that helps processing more files in parallel, that could already be enough of a benefit for some.

If you use brotli with big files, it compresses less than gzip.
Parallelism may be a thing, but I'm not sure how that would work. Clouds do not rent GPU for web traffic compression offloading, afaik. Maybe for custom deployments?