Post B68wCcuDZnCtwzeXQW by azonenberg@ioc.exchange
(DIR) More posts by azonenberg@ioc.exchange
(DIR) Post #B68rknAXQOYJr9l5Vo by azonenberg@ioc.exchange
0 likes, 0 repeats
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.
(DIR) Post #B68sJZGR7AKOrn6F28 by azonenberg@ioc.exchange
0 likes, 0 repeats
Like even drawing a selection on parts of this image is making GIMP slow. it's just a list of polygon vertices for the outlined area, this should be *trivial*. Especially since dragging to make a selection can't have a resolution greater than the currently displayed pixel size.
(DIR) Post #B68tCE0JrO7WrCcivI by azonenberg@ioc.exchange
0 likes, 0 repeats
@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
(DIR) Post #B68tZAu9Y9i3u9gONE by azonenberg@ioc.exchange
0 likes, 0 repeats
@choofa First order estimate, if it's 5 layers @ 800 Mpix RGBA32, the pixel data should be O(16 GB).
(DIR) Post #B68td2QL1WSqlBZyDo by azonenberg@ioc.exchange
0 likes, 0 repeats
@choofa But "drawing a polygon on the image to select a region I am later going to crop/flood fill/whatever" should be fast, it's a simple vector operation that doesnt have to touch the pixels at all.
(DIR) Post #B68tjCCjZYYmpc9V3I by azonenberg@ioc.exchange
0 likes, 0 repeats
@choofa When I'm doing something like rotating the image, that's an embarrassingly parallel operation that if properly implemented is mostly memory bound. Some level of care in the order of operations will ensure good cache hit rates, but for the most part every output pixel is independent of every other.
(DIR) Post #B68txksPSVqiQ4aWEy by azonenberg@ioc.exchange
0 likes, 0 repeats
@choofa Looking at CPU load I see GIMP threading some of the operations while other seem to saturate a single core. I think a lot of it is simply the tool not being designed for handling gigapixel-sized images so operations that are normally negligible run time on smaller images become major bottlenecks because nobody thought to architect it for scalability.I really am going to end up building a custom tool for this one day, I can feel it. Things like having vector annotations on top of bitmap graphics (I don't need to rasterize text as bitmaps 1:1 with the image resolution), arbitrary multilayer polygon mesh warping... One day.
(DIR) Post #B68vHTLeRFMtnnEP9k by azonenberg@ioc.exchange
0 likes, 0 repeats
A few quick tests:* One layer visible, turning on another layer: 13 seconds until the new layer is fully drawn. These should be mipmapped at various LODs with the currently visible texture enabled in <1 frame.* Rotating one layer by 0.2 degrees: 2 min 29 sec for the transform, plus about another 13 sec to redraw after it's done
(DIR) Post #B68vjNQQ3P7NXYldlw by azonenberg@ioc.exchange
0 likes, 0 repeats
Rotating is basicallyFor each output pixel* Multiply by a rotation matrix to determine the nominal input pixel location* Bilinearly interpolate from the four adjacent input pixels since the output is likely not exactly aligned to an input pixel* Write to the outputSo basically you have a couple FMAs for the coordinate transformation, a texture fetch with four memory reads and some weighted averaging, and a texture store.To a first order for 800mpix this is going to be memory bound with 3.2 Gpix of reading and 800 Mpix of writing. With a good choice of access patterns, cache locality should be decent.Assuming RGBA32, 3.2 Gpix of fetches with 0% cache hit rate is 12.8 GB of memory reads. This should be doable in well under a second on a modern GPU.
(DIR) Post #B68w6L1V9NImke3qdM by cliffordheath@mastodon.social
0 likes, 0 repeats
@azonenberg there should be no matrix math in image rotation. The fast way to do it is two orthogonal shear transforms
(DIR) Post #B68wCcuDZnCtwzeXQW by azonenberg@ioc.exchange
0 likes, 0 repeats
@cliffordheath Interesting, I'll have to think about how the decomposition works.In either case though, you end up being memory bound doing a bilinearly interpolated texture fetch for each output pixel.
(DIR) Post #B68yJ4NwWN8cp2ky12 by 1div0@mastodon.social
0 likes, 0 repeats
@azonenberg Challenge accept3D. OpenGL or Vulkan? Hope not Mental. Cheers.
(DIR) Post #B68yMdz8cNCm6OrIAq by azonenberg@ioc.exchange
0 likes, 0 repeats
@1div0 if i build it, definitely vulkan
(DIR) Post #B68yccmeqt3b0fdoo4 by 1div0@mastodon.social
0 likes, 0 repeats
@azonenberg 0xC001. NFS = Need For Speed. N33D C4F3. Will C. CU L8R 4L16470R!
(DIR) Post #B69HV8I5ixcRXVU8gK by 1div0@mastodon.social
0 likes, 0 repeats
@azonenberg Etna?