06:25nowrep: anonymix007[m]: you can use vaapi processing (va_vpp.h)
06:33Lynne: mpv has a patch which turns on frame threading for vulkan
06:33Lynne: this breaks vulkan video and seeking
07:10nowrep: i see, right, i can see corruption on seeking sometimes
07:10nowrep: anyway, the issue only seems to happen with AV1, which doesn't support threading
07:47Lynne: on intel, its a little bit sour seeing how vulkan performs in comparison to vaapi
07:47Lynne: I still get corruption in av1 sometimes
07:47Lynne: 6k hevc files don't decode
07:48Lynne: and there are threading issues that we still have to solve
08:46anonymix007[m]: nowrep: thanks for the suggestion. Can it handle 0x020000000056bb03 to 0x0200000000401b03 (AMD) or 0x0 to 0x0100000000000009 (Intel) with either XB24 to XB24 or to NV12 format conversion?
08:49nowrep: AMD yes, Intel no idea you'll need to try
09:18anonymix007[m]: I guess not, at least not with the GStreamer's vapostproc.
09:18anonymix007[m]: What is generally the faster way: OpenGL compute shaders or va postprocessing?
11:22karolherbst: alyssa: do I unsderstand nir_opt_reassociate correctly, that constant sources will be moved to the start of the chain instead of the end?
11:38alyssa: karolherbst: yes
11:38alyssa: that has a number of benefits on average
11:38karolherbst: mhhhhhhh, troublesome... we kinda need the reverse for load/stores
11:38alyssa: promoting constant folding being the obvious one
11:38karolherbst: we can fold constant offsets directly into load/store instructions
11:39alyssa: (1 + x + y + z + 1) will be reassociated as (1 + 1) + x + y + z which constnat folds
11:39alyssa: then you'll need your own pass that runs after nir_opt_reassociate
11:39karolherbst: yeah.... I'm working on that already anyway
11:39alyssa: or a different mode for reassociate
11:39karolherbst: you've seen https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36113 already anyway
11:39alyssa: actually we could probably do that as a mode on nir_opt_reassociate, we already have all the infrastructure there
11:39karolherbst: but I want something more competent
11:40alyssa: I was gonna say "no" but I commented apparently
11:40alyssa: another benefit of doing it this way:
11:40alyssa: say you have "vgpr + sgpr + #constant"
11:40karolherbst: yeah... soo the thing is.. we can do this as part of the load/store in one thing
11:40alyssa: we associate as "(#constant + sgpr) + vgpr" which saves you a vector add
11:41alyssa: whereas if you did the constant last, you end up with 2 vector adds instead of 1
11:41alyssa: (and higher VGPR pressure)
11:41karolherbst: well.. we have 0 adds
11:41karolherbst: in either case
11:41alyssa: but only for i/o
11:41karolherbst: yeah
11:41alyssa: nir_opt_reassociate is an ALU optimizer
11:41karolherbst: maybe we want special handling for chains used in IO
11:42alyssa: you run that to optimize ALU
11:42alyssa: and then you have your special I/O thing only for NVIDIA because other hw works differently
11:42alyssa: or even better we just merge
11:42alyssa: jnoorman: 's stuff and all of the adds go away in the first place
11:42karolherbst: could let reassociate do its thing, and then we reshuffle specifically for IO ops
11:42karolherbst: but yeah.. the IO ops are a bit crazy being able to take a vector, scalar and constant offset in one go
11:43karolherbst: so we kinda need adds last and the constant moved to the end
11:45alyssa: again that's going against the grain of ALU outside of the special I/O instruction so shrug
11:45karolherbst: yeah.. I'll figure something out
13:49teronimozuck: I specify the first pseudo code that i have had luck on accessing elements here. -57-192-172-176+84+84+84+270=-75 441=228+171+42 where 135-114=21*2 is 42 or 57+114−118−118−118+192+232+200=441 , it turns out that 441-75-270=96 and 96*2 which is the needed 192 for 114 to yield a single from 114 (twice a value gotten earlier that had always been successful, but finally i have been able to
13:49teronimozuck: avoid division by two). I thank gnome-calculator developers again and again, i have huge depression and i would not had been able to get there without the scrollable memory of that software.
15:00teronimozuck: Now to unlock that unheard amount of memory for computing, perhaps first steps before the filesystem and execution impl. development is to express a set of formulas in integral computation, so i intend to set up some mathml environment and provide a PDF with the needed stuff in there.
15:18teronimozuck: <teronimozuck> Where Albert Einstein worked on e=mc2, the formula is pretty simple, and it really appears that my formula though collapsed from simplified to subformulas in ecosystem is simple too. But it needed tremendous amount of dedication for whatever reason to get there at least in my case. But on the natural side linux has taken off for world class domination in sw. And i think we
15:18teronimozuck: work together on further modern improvements , it's been so complex on my own where all hard has been achieved so far, that i think it's gonna go quicker to the needed status if i involve many others like linux did in the development.
17:15teronimozuck: You liked the magic numbers , i already offered 42 magic before now 666 and 777, but i was so obsessed with division that i could not stop before i made it, however it's possible to live without, how i think is that success anchors or bases on something like derivatives, where the rate of change is measured by 25 50 75 percent or something of the circle , that hack works on sequences
17:15teronimozuck: too. 114+114+114+114+114+114+114+114−135=777 so you go in pairs and all are duplicates then −57−57−57−57−57−57−57+135=-264 777-264=513 and 513-114-114-114-114 aka the -57-57-57-57-57-57-57-57 is indeed 57, so try to learn this out.
18:44pinchartl: I fear the answer to this question won't make me happy, but I'll ask nonetheless
18:44pinchartl: I have a display engine with a blender
18:44pinchartl: it supports either global alpha *or* framebuffer alpha
18:45pinchartl: if I enable global alpha, the alpha channel of frame buffers is ignored
18:46pinchartl: is that compatible with how KMS exposes alpha to userspace ?
21:11zamundaaa[m]: [@_oftc_pinchartl:matrix.org](https://matrix.to/#/@_oftc_pinchartl:matrix.org): alpha is expected to be multiplied with the plane contents
21:13zamundaaa[m]: You could allow it for opaque buffers and reject commits with non-one alpha if the buffer also has an alpha channel
21:14zamundaaa[m]: Or add a new property for alpha replacement though