00:32 <pinchartl> graphitemaster: I get the same feeling reading pretty much any GL extension spec :-/

00:36 <pinchartl> robher: is there an official DT overlay specification ? I have an overlay that dtc compiles without warning or error and that U-Boot apply partly only, silently ignoring parts of it. I think my overlay is wrong, but without a spec I can't tell which of dtc or U-Boot (libfdt really) should be fixed

00:54 <graphitemaster> Either I have no clue how to properly use interlock or interlock is actually just buggy.

00:55 <imirkin> graphitemaster: most likely a happy combination

01:04 <graphitemaster> What's a good way to read and write to the same pixel in a fragment pass in a safe synchronized manner

01:05 <imirkin> graphitemaster: bind the fb as an image

01:05 <imirkin> and use imageStore/imageLoad

01:05 <graphitemaster> I tried that first, it's corrupted as hell on AMD. Seems to work fine on NV.

01:06 <imirkin> did you mark the image as ... something

01:06 <imirkin> coherent?

01:06 <graphitemaster> coherent readonly image2D yeah

01:06 <imirkin> wait, readonly?

01:07 <imirkin> i mean don't bind as fb at all

01:07 <imirkin> use ARB_framebuffer_no_attachments style

01:07 <imirkin> and do all the reading/writing via image*

01:09 <graphitemaster> Doing that now, doesn't seem to work either. I have a single `restrict coherent uniform image2D` of type r16f, I do a imageLoad at the top, discard in the FS when >= 1.0, otherwise I do things and write out with imageStore, it's always at coordinate gl_FragCoord.xy, and every random run I get different corrupted results.

01:10 <imirkin> is the fb bound?

01:10 <imirkin> i mean

01:10 <imirkin> is anything bound as the fb?

01:10 <graphitemaster> separate texture from the fbo textures in this case, but yes the fbo has other attachments I'm drawing into as well

01:11 <graphitemaster> Oh

01:12 <graphitemaster> glMemoryBarrier after the glClearTexImage but before the glDraw seems to have made things consistent

01:12 <graphitemaster> I guess there's no syncronization between a clear and a draw!?

01:32 <imirkin> a clear and a draw, yes. a ClearTexImage and a draw? no.

01:33 <HdkR> fb_fetch likely won't ever exist for Nvidia and AMD hardware. You'll have to live with Intel and mobiles :P

04:27 <alyssa> EXT_shader_framebuffer_fetch drivers say aye

04:27 <alyssa> Aye!

04:30 <dcbaker> I thought phoronix had trouble with the details of what goes on here: https://www.tomshardware.com/news/ati-radeon-gpus-get-driver-optimizations-linux

04:34 <imirkin> second-hand info is always better than first-hand

04:34 <imirkin> fta, "according to phoronix, ..."

05:34 <HdkR> alyssa: plez write a blend shaders extension to GL and Vulkan ;)

15:02 <robher> pinchartl: No, only the docs in the kernel tree.

20:05 <Ristovski> Is there a way to use DRI_PRIME with MESA_LOADER_DRIVER_OVERRIDE?

20:09 <imirkin> sure

20:17 <Ristovski> imirkin: But there isn't a way to specify the other PRIME driver on a hybrid system

20:17 <Ristovski> so I cannot choose between i965+amdgpu and crocus+amdgpu for example

20:17 <imirkin> huh?

20:17 <imirkin> sure you can

20:18 <imirkin> maybe i don't understand the setup

20:18 <imirkin> you can only have 1 gpu at a time

20:18 <imirkin> so when you want radeonsi, you can just do "DRI_PRIME=1"

20:18 <pinchartl> robher: my overlay had "/ { panel { ... }; };" instead of "${/} { panel { ... }; };". should dtc have complained ? fdtoverlay seems to have applied it correctly

20:18 <imirkin> when you want crocus, you can do "MESA_LOADER_DRIVER_OVERRIDE=crocus"

20:19 <Ristovski> imirkin: Hmm wait, so using DRI_PRIME=1 does not load the iGPU driver? I guess it makes sense if there is no need

20:19 <Ristovski> I was under the assumption it had to load both

20:19 <imirkin> no

20:19 <imirkin> shouldn't!

20:19 <imirkin> there could be some silly thing i'm not thinking of, of course

20:20 <imirkin> with X, the ddx is meant to copy the contents over

20:20 <imirkin> with wayland, the display manger is

20:20 <imirkin> the application itself just has 1 gpu

20:21 <Ristovski> Huh, interesting. I ran `DRI_PRIME=1 LIBGL_DEBUG=verbose glxgears` and libgl prints: "using driver amdgpu for 7", "using driver i915 for 5" and "pci id for fd 5: 8086:0a16, driver crocus"

20:22 <imirkin> i think that's just the loader saying what driver it would use?

20:23 <Ristovski> Seems to be the case, only radeonsi_dri.so gets loaded into the process

20:26 <robher> pinchartl: You'd have to check with someone that pays attention to overlays. ;)

20:56 <alyssa> HdkR: I don't expect any non-Malis could support it efficiently

20:56 <alyssa> and even on Mali, it's dicey

22:13 <HdkR> alyssa: Dicey things? Sounds perfect for an extension :D