23:49 | illwieckz | joined the channel | |
02:35 | Bertl | off to bed now ... have a good one everyone!
| |
02:35 | Bertl | changed nick to: Bertl_zZ
| |
06:04 | elafon | left the channel | |
06:04 | elafon | joined the channel | |
07:17 | se6astian | good day
| |
10:19 | Bertl_zZ | changed nick to: Bertl
| |
10:19 | Bertl | morning folks!
| |
14:06 | aombk3 | joined the channel | |
14:10 | aombk2 | left the channel | |
14:10 | aombk | joined the channel | |
14:13 | aombk3 | left the channel | |
14:20 | aombk | left the channel | |
16:00 | se6astian | MEETING TIME, who is here?
| 16:00 | Bertl | is here ...
|
16:03 | se6astian | anyone else?
| |
16:03 | se6astian | vup/anuejn news to share with the gerneal public?
| |
16:04 | se6astian | Bertl: do you have news for us?
| |
16:04 | vup | well I can talk a bit about the recent changes for axiom-firmware and axiom-recorder
| |
16:04 | se6astian | great, please do
| |
16:06 | vup | sure, so let start with axiom-recorder. anuejn and I have been developing it almost exclusively on iGPU platforms, which can access the main system RAM with essentially the same performance as any device local memory (because they actually don't have any device local memory and are using the main system RAM as memory)
| |
16:07 | vup | We made extensive use of this fact to avoid unnecessary data copies, for example the output of the debayerer (which runs on the gpu) get written to a buffer that is directly accessible from the gpu and thus the debayered frames can then directly without any copy be passed to further processing (for example writing them to a file or encoding them using ffmpeg)
| |
16:08 | vup | As it turns out, these cpu accessible buffers are also available on dGPUs, but are incredibly slow, because they are allocated in the main system RAM and make every access by the GPU go over PCIe to the main system RAM
| |
16:09 | vup | so on these we actually have to use device local memory and copy the data from cpu accessible buffers to device local buffers
| |
16:09 | vup | this unfortunately means there are more data copies involved, however for some reason this is even faster on iGPUs :)
| |
16:10 | vup | on a 64 core system with a 1080 Ti this made a basic `read raw12 -> convert to bitdepth 8 -> debayer` flow go from ~20fps to ~750fps
| |
16:11 | vup | and on my laptop it made the same flow + a final rendering of the result go from ~160fps to ~200fps
| |
16:11 | vup | these changes are currently still wip and only a few of the processing nodes have been converted, but converting the rest should not be too tricky
| |
16:11 | vup | (we are working on it here: https://github.com/apertus-open-source-cinema/axiom-recorder/pull/8)
| |
16:13 | vup | finally se6astian and I did a session yesterday to get the new raw mode supported on fw 2.x (https://github.com/apertus-open-source-cinema/axiom-firmware)
| |
16:14 | vup | the required changes were actually quite minimal and the integration is basically done, but we are still working on a problem that now occured with the normal (not raw) output :)
| |
16:15 | vup | (the integration is tracked here: https://github.com/apertus-open-source-cinema/axiom-firmware/pull/188)
| |
16:15 | vup | I think thats it
| |
16:15 | Bertl | no relevant news from my side this week ...
| |
16:15 | se6astian | many thanks vup, incredible work!
| |
16:16 | se6astian | I tried the raw12 sequence playback myself and its absolutely stunning to view it in realtime
| |
16:16 | se6astian | quick updates from my side:
| |
16:16 | se6astian | I benchmarked the m.2 pcie ssd on a fast pc with direct PCIe connection
| |
16:17 | se6astian | results are here
| |
16:17 | se6astian | https://docs.google.com/document/d/1Y3UVPmJ3kzAAtcH0plMICJ2-Z7EOZl4OhE2_RcXdz2U/edit
| |
16:17 | se6astian | writing zeros is fast
| |
16:17 | se6astian | writing actual data starts fast
| |
16:17 | se6astian | and then continously drops until we go below the required datarate the Beta supplies
| |
16:18 | se6astian | so it seems the SSD is simply unsuitable for our application
| |
16:19 | se6astian | I adapted the PCB brackets design as there was an issue with top/bottom cap slightly interfering in the CP enclosure
| |
16:19 | se6astian | new design was 3d printed
| |
16:19 | se6astian | and installed and now everything fits fine
| |
16:19 | se6astian | for me this is the perfect solution already, also for production
| |
16:20 | se6astian | had a VC today with the folks at the technical university vienna we want to collaborate with for CP enclosure part manufacturing and optimization
| |
16:21 | se6astian | I want to see if we can participate in the virtual FOSDEM and CCC online events some way
| |
16:21 | se6astian | CCC CFP ends in about a week
| |
16:21 | se6astian | FOSDEM CfP isnt open yet
| |
16:21 | se6astian | CCC has local events and local stages though (none in Austria) so the concept isnt 100% clear to me yet
| |
16:21 | se6astian | how the event will actually take place
| |
16:22 | se6astian | we started looking for someone to help us with color science and raw processing here: https://www.magiclantern.fm/forum/index.php?topic=26299.0
| |
16:23 | se6astian | if you know someone who could help here please share
| |
16:23 | se6astian | or spread the call whereever it might make sense
| |
16:23 | se6astian | GSoC mentor summit was also last week
| |
16:23 | yasmin | joined the channel | |
16:23 | se6astian | where quite significant changes for the program next year were announced
| |
16:24 | se6astian | https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html
| |
16:24 | se6astian | which will also affect us
| |
16:24 | se6astian | thats it from my side I think
| |
16:24 | se6astian | anyone else who wants to report news?
| |
16:24 | se6astian | yasmin: hello, any news from your side?
| |
16:25 | vup | se6astian: is this the only m.2 ssd you have tested so far, or did you test others already (lost the overview a bit in the ssd testing saga :)
| |
16:25 | yasmin | hello! i'm still working on my task (updating the camera HDL to 2021 version) i faced an error which i'm trying to figure it out (after my midterms this week)
| |
16:26 | se6astian | yeah its indeed quite confusing, I tested a few already but few natively connected only on rockpi and now this test machine
| |
16:26 | se6astian | in USB3 enclosure results are completely different
| |
16:27 | se6astian | ordered a 2017 NUC and lattepanda Alpha 864s
| |
16:27 | se6astian | which also have native PCIe NVME SSD support
| |
16:27 | vup | right, was just trying to correlate a few data points with the SusWrite benchmark here: https://ssd.userbenchmark.com/
| |
16:28 | se6astian | the PNY CS3030 has an advertized 3000MB/s write speed...
| |
16:28 | vup | well yes, but under which benchmark
| |
16:28 | se6astian | the problem seems to be that every benchmark does things differently
| |
16:28 | se6astian | some just write a few GB of zeros
| |
16:29 | se6astian | I didnt find any benchmark that does pseudo random data writes over the full SSD capacity
| |
16:29 | se6astian | thats what Bertl benchmark tool does
| |
16:29 | vup | anandtech has some benchmarks they call whole-drive sequantial write, for example here: https://www.anandtech.com/show/13512/the-crucial-p1-1tb-ssd-review/7
| |
16:30 | vup | i guess recording similar graphs like they did there would be interesting aswell
| |
16:31 | se6astian | thanks
| |
16:31 | se6astian | will see what NUC/lattepanda reach with this SSD but I guess as next step will source another SSD that has very high benchmark results on anandtech
| |
16:32 | se6astian | samsung 980 PRO also looks promising
| |
16:33 | se6astian | rockpi doesnt support all lanes and not newest PCIe so its possible even high end ssds perform poorly on it
| |
16:33 | se6astian | NUC should get close to real performance limit though I hope
| |
16:33 | vup | yeah iirc the rockpi benchmarks were a bit weird
| |
16:33 | se6astian | thanks for the update yasmin!
| |
16:34 | se6astian | anyone else with updates/news?
| |
16:35 | se6astian | then many thanks all participants, MEETING CONCLUDED!
| |
16:35 | Bertl | thanks for moderating!
| |
16:36 | yasmin | Thanks
| |
16:36 | yasmin | left the channel | |
16:49 | Bertl | off for now, bbl
| |
16:49 | Bertl | changed nick to: Bertl_oO
|