Code: Select all
fast:
Multi-threaded copy between CPU and GPU at the expense of 4x memory consumption.
Default True.P.S: I really would like to see its AVS+ native by your talented hands.
Port Cube
Port Cube
I was reading https://github.com/WolframRhodium/VapourSynth-BM3DCUDA and I noticed:
Perhaps you can find some trick in the source to increase transfer speed.
P.S: I really would like to see its AVS+ native by your talented hands.
P.S: I really would like to see its AVS+ native by your talented hands.
Port Cube
And now, it's time for a message from our sponsor.
Port Cube
Ha ha, Boris! Very timely.
Stunning visuals in that Rocket Man video, Balti. Great find.
This is how I'm feeling these days. Take my word, I'm a madman, don't you know?
Stunning visuals in that Rocket Man video, Balti. Great find.
This is how I'm feeling these days. Take my word, I'm a madman, don't you know?
Port Cube
And now we return you to our regularly scheduled program.
Port Cube
Great one, hydra3333. Awesome tribute to Vincent, the tortured soul.
OK, so the z code returns values of Kr and Kb that I can inspect. Kg is 1 - (Kr + Kb). Then it all goes into AVX512 etc. And the stupid STL and object-oriented filter graph crapola makes it impenetrable. No comments in the code either. Not trying to ding z. I'm sure it's just great for genius-level humans, but I'm a primitive rodent and so use only procedural code without all the crapola. Look at thdmerge source to see the kind of code I like. However, there is a standard way to convert Kr/Kb/Kg to actual matrix equations. I'll do that and see what results viz-a-viz my equations.
@tormento
What is the claimed speedup for the 'fast' mode you described? I'm just not grokking how multithreading can make a significant difference. The bottleneck is simply the amount of data versus the available PCIe bandwidth. Kernel launch, etc., is insignificant compared to that. I keep saying this but nobody gives up the magic!
OK, so the z code returns values of Kr and Kb that I can inspect. Kg is 1 - (Kr + Kb). Then it all goes into AVX512 etc. And the stupid STL and object-oriented filter graph crapola makes it impenetrable. No comments in the code either. Not trying to ding z. I'm sure it's just great for genius-level humans, but I'm a primitive rodent and so use only procedural code without all the crapola. Look at thdmerge source to see the kind of code I like. However, there is a standard way to convert Kr/Kb/Kg to actual matrix equations. I'll do that and see what results viz-a-viz my equations.
@tormento
What is the claimed speedup for the 'fast' mode you described? I'm just not grokking how multithreading can make a significant difference. The bottleneck is simply the amount of data versus the available PCIe bandwidth. Kernel launch, etc., is insignificant compared to that. I keep saying this but nobody gives up the magic!
Port Cube
Not a loss of time. Keep all ideas coming.
Port Cube
Perhaps you already know:
https://github.com/FranceBB/LinearTransformation
They reversed engineered DoVi too.
https://github.com/FranceBB/LinearTransformation
They reversed engineered DoVi too.
Port Cube
Who should I ask to get this project to resume? 
At least for Christmas
At least for Christmas
Port Cube
Aren't those standard?Bullwinkle wrote: ↑Fri Dec 09, 2022 9:12 amwe need a specification of the equations used for the YUV<-->RGB conversion. Perhaps the author could provide one of those.
https://en.wikipedia.org/wiki/YUV#:~:te ... %20format.
Port Cube
Dear ones,
is there any chance that we can see some progression in DGCube development?
It stopped while thinking about some more color space and conversions.
is there any chance that we can see some progression in DGCube development?
It stopped while thinking about some more color space and conversions.
Port Cube
Nice song.
Anyway proper colorspace path to have direct PQ to HLG would be really useful.
Anyway proper colorspace path to have direct PQ to HLG would be really useful.
Port Cube
Just not interesting. Pecuniary compensation could change that.