pmc.ncbi.nlm.nih.gov/articles/…
Risk stratification for future cardiac arrest after COVID-19 vaccination - PMC
Unheralded cardiac arrest among previously healthy young people without antecedent illness, months or years after coronavirus disease 2019 (COVID-19) vaccination, highlights the urgent need for risk stratification. The most likely underlying ...pmc.ncbi.nlm.nih.gov
Sebastian Krzyszkowiak
in reply to Pavel Machek • • •No, it's
RGRGRG
GBGBGB
You lose meaningful data if you ignore half of green pixels.
I see no reason why it couldn't be done. Just take care not to introduce needless copies in your processing path. dmabufs are your friends.
Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •tizilogic
in reply to Sebastian Krzyszkowiak • • •@dos
adding to that, what data type is the image data (float, int, ???) and what data type is expected to come out?
instead of trying to outsource to the GPU, have you considered SIMD? (I assume librem5 and pinephone support NEON)
if the GPU is better suited, another question is whether there's support for compute shaders on the respective GPUs (what is the supported OpenGL version, assuming there is no Vulkan support on these devices)
Sebastian Krzyszkowiak
in reply to tizilogic • • •@tizilogic It's either 8-bit int, or 10-bit int stored as 16-bit.
GC7000L supports compute shaders, but etnaviv isn't there yet.
Naive debayering is easy, but for good picture quality you need much more than that.
Pavel Machek
in reply to Sebastian Krzyszkowiak • • •@dos As for copies... Yes, I'm currently doing more copies than needed. I measured Librem 5 at about 2GB/sec memory bandwidth, and stream is about 30MB/sec. At 1Mpix/24fps resolution, gstreamer should be able to encode it in real time.
Here's huge problem with v4l, which gives uncached memory buffers to userspace. That means one whole CPU core is dedicated to copying that to "normal" memory. If that is ever solved, yes, other optimalizations are possible. Currently, this means it is not even possible to copy anything bigger than 1Mpix out of the v4l.
Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Megapixels is not an example of how to do things in the most performant way 😀 OpenGL operates in a VRAM-centric model, it's very copy-heavy. We don't need to copy things around, as our GPUs operate on the exact same memory CPUs do.
See GL_OES_EGL_image_external and docs.kernel.org/userspace-api/…
3.4. Streaming I/O (DMA buffer importing) — The Linux Kernel documentation
docs.kernel.orgPavel Machek
in reply to Sebastian Krzyszkowiak • • •@dos Sorry, hero, that's dark magic behind my understanding. I see the words but don't understand the sentences. 🙁
I'd need working example here. I got surprisingly far vibecoding this, but even robots have their limits.
Sebastian Krzyszkowiak
in reply to Pavel Machek • • •After eliminating glReadPixels and having the output buffer mmaped instead: "18.9 MB in 0.08s = 244.4 MB/s"
After putting glTexImage2D out of the loop to emulate zero-copy import from V4L as well:
"18.9 MB in 0.05s = 400.1 MB/s"
dosowisko.net/stuff/bwtest.pat…
Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Also, it gets faster when you increase the buffer size, because rendering is so fast you're mostly measuring API overhead 😁
With full 13MP frames: 315.1 MB in 0.62s = 511.3 MB/s
Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •I left the memcpy line commented out for a reason - with it uncommented, the result is exactly the same as with glReadPixels (which is effectively a memcpy on steroids). The point is to pass that buffer to the encoder directly, so it can read the data straight from the output buffer without waiting for memcpy to conclude.
I've also verified that the approach is sound by having the shader output different values each frame and accessing it via hexdump_pixels inside the loop. Still fast ;)
Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •@dos But you only hexdumped first few pixels, right?
Is that buffer uncached or something?
I pushed current code to gitlab.com/tui/debayer-gpu .
Yes, with memcpy(), I'm getting same results as before. If I get rid of the memcpy(), and attempt to fwrite() the buffer directly, things actually slow down.
I can't easily connect gstreamer to that, I'm going through ramdisk for now. I'm using time ./ocam.py debayer for testing -- gitlab.com/tui/tui/-/blob/mast…
tui / debayer-gpu · GitLab
GitLabSebastian Krzyszkowiak
in reply to Pavel Machek • • •> I can't easily connect gstreamer to that
Why not? I quickly hacked up passing dma-bufs to GStreamer and even though I'm glFinishing and busy-waiting on a frame to get encoded sequentially it still manages to encode a 526x390 h264 stream in real time on L5.
Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •paste.debian.net/1384224/
It's ugly, hardcodes everything, lies on frame timing, occasionally segfaults. Most of it is copied straight from LLM, I just massaged the pieces to work together. Not the kind of code I'd like to sign off on 😀 But it's a working example, so have fun with it.
debian Pastezone
paste.debian.netSebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •@dos Exactly. That's a bit of big deal. That's why I'm trying to make sure this code does not go away. I had phase-detection auto-focus working at one point, but decided it is unusable as I did not see a way to scale down images quickly enough.
Plus it also adds possibility of zooming.
Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •@dos 😀 Hopefully. I'll believe things when I see them running locally.
BTW there's one more important thing this can probably do: take full-resolution photos while recording video.
Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Toggling the killswitch makes it appear though.
IIRC PDAF was also usable at half-res.
RAW10 is just a matter of setting up clocks for higher bandwidth and more lanes. Switching data format is then just a single register away.
Pavel Machek
in reply to Sebastian Krzyszkowiak • • •@dos Fences; that must be some kind of dark magic.
This code seems too good to be true. So, just to be sure, and in case you disappear tomorrow, can I add /* Copyright 2025 Sebastian Krzyszkowiak, GPLv2 */ and act according to that?
Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Good question. Not sure what license would be appropriate to put on something that's mostly an output of a model trained on code on all sorts of licenses anyway...
But given that it's just a bit of glue code between three APIs put together as an example, consider it to be under MIT-0 😜
Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •When I lie to GStreamer and tell it that its input is in YUY2, it gets faster - perhaps even fast enough to encode at 1052x780. That's another opportunity for improvement.
(and there's nothing magic about fences, it's just a simple synchronization primitive 😛)
Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •@dos Okay, I pushed code to gitlab.com/tui/tui/-/tree/mast… . Debugging this may be a bit "fun".
Do I guess correctly that shaders can do arbitrary resolutions, such as 800x600?
I like the v4l+shaders integration. I'm not sure if I like the v4l+shaders+gstreamer integration.
icam · master · tui / Tui · GitLab
GitLabSebastian Krzyszkowiak
in reply to Pavel Machek • • •Yes, of course.
BTW. Turns out that streaming to YouTube instead of a local file is just a matter of using rtmpsink instead of filesink 😁
Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •For GTK: either docs.gtk.org/gdk4/class.Dmabuf… or gstreamer.freedesktop.org/docu…
For SDL with GL: just import it the same way V4L buffers are imported.
Frankly, it's flexible enough that your choice of toolkit should only depend on other factors.
Gdk.DmabufTextureBuilder
docs.gtk.orgPavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Sebastian Krzyszkowiak
in reply to Pavel Machek • • •That one line is the only thing that runs from another thread and it's neither scary nor requires any locking 😁
But there are several other smelly things in this code and lots of missing error handling, so I'd rather start with that when looking for suspects.
Sebastian Krzyszkowiak
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •Pavel Machek
in reply to Sebastian Krzyszkowiak • • •tui / debayer-gpu · GitLab
GitLabPavel Machek
in reply to Sebastian Krzyszkowiak • • •bwtest · master · tui / debayer-gpu · GitLab
GitLabSebastian Krzyszkowiak
in reply to Pavel Machek • • •datenwolf
in reply to Pavel Machek • • •Pavel Machek
in reply to datenwolf • • •@datenwolf Example of frame is here: gitlab.com/tui/tui/-/blob/mast… (I also have frame generator and real frames captured from libobscura).
Anything that works on Librem 5 is fine, bonus points if I can understand it. Robot generated code using -lEGL -lGLESv2 -lm ... and that builds and does something. Librem 5 reports:
Vendor: etnaviv
Renderer: Vivante GC7000 rev 6214
OpenGL Version: OpenGL ES 2.0 Mesa 21.2.6
GLSL Version: OpenGL ES GLSL ES 1.0.16
ucam/bayer2rgb.rs · master · tui / Tui · GitLab
GitLabdatenwolf
in reply to Pavel Machek • • •Anyway, spent the day finding a nice polynomial to linearize the sensor values (LUTs should be avoided if possible, memory access has latency and costs energy, if you can calculate in a few instr. prefer that).
Pavel Machek
in reply to datenwolf • • •@datenwolf I believe I'm limited to OpenGL ES 2.0. Presumably hardware can do more but our current drivers can not, so we are stuck there.
On the other hand... #librem5 main sensor can not do 10bpp at the moment, due to missing drivers. So maybe we can focus on 8bpp, first. Probably ineffecient conversion is "good enough" too, as GPU is a bit overpowered for this job.
Sebastian Krzyszkowiak
in reply to Pavel Machek • • •