Egregoros

I really don't need a new project, but I would love a clustered and/or GPU accelerated image editor for massive images.

Something that can comfortably and performantly rotate, crop, layer stack, align, etc. images at gigapixel scale without bogging down for minutes at a time even on my big iron.

Across my lab I can harness something like 160 physical / 320 logical CPU cores, 1.3 TB of RAM, 50+ GB of VRAM, and more shader cores than I feel like counting.

Everything is or will soon (after I swap a few NICs) be connected by 40/100GbE.

Deleting part of a layer in an 0.8 gigapixel image with five layers, with that much compute available, doesn't seem like it should be the kind of thing I have to sit and watch GIMP updating scanline by scanline.

@petrillic All of my Windows boxen are VMs and my one mac is a Mini with 16GB of RAM that probably can't even open a file this big much less edit it.

The other thing is, it needs to not assume it can fit the entire image into VRAM. Like, this particular image and workstation combo would probably work (it's ~800mpix, 5 layers, so ~4 Gpix, at RGBA32 that's 16GB and my new GPU has 32GB of VRAM) but anything much bigger would not.

So intelligently managing transfers between CPU and GPU to do the transformations will be part of the requirements for such a tool to avoid getting horribly bottlenecked on PCIe bandwidth

Thinking about decoding some of the more complicated protocols in ngscopeclient more fully on the GPU.

Let's take I2C. for example. I have a 2x 10M point capture coming off my STM32MP2 / Kintex-7 testbed that takes about 188 ms to decode on the Xeon 4310 on my lab workstation (lots of idle time with just a few packets).

The decode can accept either sparse or uniformly sampled data; right now it's getting uniform data at 100 Msps which is overkill but the ThunderScope doesn't yet let you decimate to go any slower.

So for the "sampling at many times the symbol rate" use case, the easiest GPU win might be to delta code uniformly sampled data and store SDA/SCL separately as a sparse waveform (i.e. sample value), start time, duration).

But that also involves storing and reading back from a temporary memory buffer (which will have to be as big as the waveform, since there's no way to know in advance how many I2C events there will be).

Which brings us to the second option: try to implement the entire decode inner loop in a shader.