06:42 mripard: sima, mlankhorst: it looks like drm-misc-next isn't in linux-next because of the new patch in drm-misc-next-fixes
06:43 sima: mripard, I guess force push it away and put it into the right tree?
06:43 mripard: I'm wondering if we shouldn't just mark drm-misc-next-fixes as ro on gitlab
06:43 mripard: and open it when we actually want it to
06:44 sima: hm, could I guess, but also yet another step to make sure is done each release ...
06:45 mripard: hopefully it's something that people will remind us of if we forgot :)
06:55 sima: mripard, yeah I guess ping tzimmermann and mlankhorst and then flip it
08:00 mripard: jani: have you seen https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/41 ?
08:15 mlankhorst: sima: shall I reset next-fixes to v6.10-rc1?
08:26 sima: mlankhorst, chat with mripard
08:30 mripard: mlankhorst: the drm-misc-next-fixes should be solved now
08:32 mlankhorst: ok good. :)
09:31 jani: mripard: EDIDs are horrible crap, news at 11 :p
09:32 mripard: jani: so should we rename your job title as horrible crap expert ? :D
09:32 jani: mripard: sounds about right
09:41 pq: sima, so if kernel cmdline is the only intended way to use the TV mnochrome mode thing, does that waive all requirements of KMS UAPI? I mean, doesn't patch add the new thing to both? Maybe the KMS property should be removed completely?
09:41 pq: or is literally implemented only for the cmdline?
11:42 tjaalton: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9507 this is now happening with 24.1 too
11:48 sima: pq, it's still for both, but it's also only for analog TV out connectors, which has a real world impact going forward of ... pretty much nothing
11:48 pq: ok
11:49 sima: like if people would come with something like this for hdmi or dp I think it's a totally different story
11:49 pq: cool
11:53 karolherbst: fyi: one of my pipelines failed due to a vc4-rpi3 not booting up: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/59897224
11:54 karolherbst: but it also downloads an image for 5 minutes?
12:15 Company: pq: did you see my question yesterday about GL_SRGB?
12:16 pq: Company, I did, but way after you asked them.
12:16 Company: I'm still wondering if my analysis is correct
12:16 Company: that premultiplied and GL_SRGB don't mix
12:17 pq: it depends, I think...
12:17 pq: I'm not sure I remember GL_SRGB operation correctly.
12:18 Company: afaiu it just maps the float to U8 values according to the srgb tf
12:18 Company: for the rgb channels
12:18 pq: and literally nothing else? only r, g, b, not alpha?
12:18 Company: yeah
12:19 pq: when sampling a texture, before filtering?
12:19 Company: I don't actually know the order for that
12:19 Company: because I was just concerned with writing
12:19 pq: oh, writing side, ok
12:20 Company: my assumption was I end up with a premultiplied linear rgb value
12:20 Company: my example is always vec4 (0.25, 0, 0, 0.5)
12:20 Company: ie semi-transparent semi-red
12:21 pq: yeah, I think you cannot produce premultiplied-in-electrical with GL_SRGB writing. You can only produce premultiplied-in-optical, if you multiply in the frag shader.
12:21 pq: color-representation extension would allow you to use premultiplied-in-optical in Wayland
12:22 Company: the question came up because I want to switch GTK to linear compositing
12:22 Company: but not lose performance
12:22 Company: and that only works when using GL_SRGB
12:23 Company: because otherwise I need to do the conversion in a shader and old GPUs don't like that
12:23 pq: right, not working as a Wayland client without color-representation, or an additional premult pass after writing
12:23 Company: (not sure they like GL_SRGB more, but I'm optimistic)
12:23 zamundaaa[m]: Company: the shader isn't the problem, the shadow buffer you need is
12:24 zamundaaa[m]: I've been thinking about switching KWin back to gamma 2.2 compositing for that reason. It doesn't always get rid of the shadow buffer, but in the most simple cases it does
12:24 Company: zamundaaa[m]: probably, yeah
12:24 pq: you may not need shadow buffer, if you can write a blending shader that decode-blend-encode for each fragment...
12:25 FL4SHK[m]: how does Mesa work regarding compiling shader code for a typical GPU?
12:25 zamundaaa[m]: pq: that doesn't work with older OpenGL
12:25 pq: swick actually wrote that code for weston a long time ago, but we haven't used it
12:25 pq: zamundaaa[m], yeah, probably doesn't
12:25 FL4SHK[m]: what does the compiler backend consist of?
12:25 FL4SHK[m]: and the compiler front end
12:26 Company: it's also too slow
12:26 Company: if you do too many srgb<=>linear conversions, the rpi slows down
12:26 Company: a desktop gpu doesn't care
12:27 FL4SHK[m]: Neat, you're discussing RPi's?
12:27 Company: but somewhere in the 2010s is the point where GPUs get slow
12:27 Company: these days memory is the slow stuff (just like on CPUs), but back then...
12:28 FL4SHK[m]: that's what caches are for
12:28 FL4SHK[m]: but... they only work so well
12:28 pq: keeping electrical blending as an option for old hardware seems like a practical solution to me
12:28 Company: pq: so I think I'll just use GL_SRGB anyway and not care about that mismatch, because most GTK apps are mainly opaque
12:29 Company: and pretty much all the inputs are non-premultiplied, so that's not an issue anyway
12:29 FL4SHK[m]: I'm developing an FPGA-based system. I wrote a GCC backend for the CPU, and I wrote a software rasterizer to learn how 3D rendering works.
12:30 pq: Company, do you do drop shadows or such? Maybe you can special-case and pre-render those?
12:30 pq: window shadows in client side
12:30 zamundaaa[m]: pq: I didn't mean it as an option, but just as what KWin will always do
12:30 Company: yes, but I think it's not worth it
12:30 FL4SHK[m]: though the CPU doesn't have virtual memory defined for it yet
12:30 Company: like, the shadows will be slightly off, but so what
12:30 pq: zamundaaa[m], in HDR mode, too?
12:31 zamundaaa[m]: Yes
12:31 FL4SHK[m]: What I want to do is port one of the open source Unix systems to the CPU, and also port Mesa
12:31 zamundaaa[m]: There we still need the shadow buffer, but it could be dropped down to ARGB2101010 instead of FP16
12:31 FL4SHK[m]: apologies, you all are having another conversation while I discuss my project.
12:32 pq: zamundaaa[m], so you'd re-code all content, HDR included, to gamma 2.2, blend, then re-code to display TF?
12:32 zamundaaa[m]: Or offload gamma 2.2 -> PQ to KMS with the ARGB2101010 buffer
12:32 zamundaaa[m]: Yeah
12:32 pq: interesting
12:32 pq: let me know how that works out
12:33 zamundaaa[m]: Will do
12:33 FL4SHK[m]: does Mesa outright require that a GPU it targets can run code in some way?
12:33 FL4SHK[m]: or can it somehow target a fixed function GPU
12:34 FL4SHK[m]: need to know so I can figure out how much work to do on my GPU
12:34 Company: zamundaaa[m]: what's the minimum GL version Kwin needs?
12:34 FL4SHK[m]: I'd certainly like to go all the way and make a SIMD machine
12:34 karolherbst: FL4SHK[m]: fixed function is usually pre OpenGL 2, and I think we only have one driver (nv30) supporting hardware like that still around.. maybe there is more?
12:34 FL4SHK[m]: But that's more work than just the fixed function components
12:35 pq: FL4SHK[m], unless I'm mistaked, all the fixed-function drivers were left in the amber branch. Gallium framework does not do fixed-function, I think.
12:35 karolherbst: so no shaders == no OpenGL 2 or newer
12:35 FL4SHK[m]: ah
12:35 zamundaaa[m]: Company: 2.0, both desktop and ES
12:35 FL4SHK[m]: I'll go ahead and make a full programmable GPU then
12:35 karolherbst: pq: nv30 supports fixed function hardware, shaders got added with nv40+ class hardware
12:36 FL4SHK[m]: but then, my question is, what is the compiler side of Mesa like for compiling shader code to target the GPU?
12:36 karolherbst: none for fixed function
12:36 karolherbst: ohh wait, for programmable
12:36 FL4SHK[m]: Yes
12:36 pq: karolherbst, and it's still in Mesa main? And non-gallium?
12:36 karolherbst: for OpenGL: glsl source code -> glsl ir -> nir -> driver
12:36 Company: zamundaaa[m]: so you want to run on pretty slow machines anyway I suppose and can't require too much - at least in your most generic path
12:37 karolherbst: for vulkan: glsl source code -> gslsvalidator -> spir-v -> nir -> driver
12:37 FL4SHK[m]: I see
12:37 karolherbst: pq: it's gallium
12:37 karolherbst: and still on main
12:37 FL4SHK[m]: do I only need to write a compiler backend for this?
12:37 pq: oh, ok
12:37 karolherbst: (which.. might not be a good idea, but ambering a single gallium driver is something we haven't done yet)
12:37 FL4SHK[m]: And is the compiler backend stuff in the Mesa driver?
12:37 Company: zamundaaa[m]: what I don't want in GTK is that HDR and SDR mode composite differently, because then your (sdr) app might change how it looks when you move it between monitors
12:37 karolherbst: FL4SHK[m]: correct
12:38 FL4SHK[m]: cool
12:38 Company: zamundaaa[m]: and I'm currently trying to figure out if I can achieve that by going linear everywhere
12:38 FL4SHK[m]: I'll look into that once the hardware is complete
12:38 karolherbst: you can also just go from nir straight to your ISA as the first step
12:38 zamundaaa[m]: Company: yeah, we need to have everything run smoothly on like 10+ year old Intel iGPUs that are connected to a 4k screen for some reason
12:38 FL4SHK[m]: Oh
12:38 FL4SHK[m]: That would be nice
12:38 FL4SHK[m]: I've done GCC backends before, as I've mentioned
12:38 karolherbst: no need to write a full backaned compiler, but you might ahve to run a lot of nir passes to make it convertable to an ISA
12:38 FL4SHK[m]: so hopefully the process is at least somewhat similar
12:39 karolherbst: yeah, should be, just a different API
12:39 FL4SHK[m]: cool
12:39 FL4SHK[m]: that makes me happy
12:39 zamundaaa[m]: I have that same goal, blending needs to look the same on HDR and SDR screens. Right now it doesn't, and that doesn't just not look nice but causes actual problems
12:40 karolherbst:wished things would run smoothly on 4K displays on 3 year old iGPUs
12:40 FL4SHK[m]: I bought a fancy FPGA dev board that I want to make a soft CPU and GPU for
12:40 FL4SHK[m]: 500k logic cells
12:40 FL4SHK[m]: So it should be a good project
12:40 FL4SHK[m]: I'm not crazy enough to also write an OS and compiler from scratch
12:40 karolherbst: yeah.. though I can expect that unless your ISA is pretty trivial it might be hard to do much there
12:40 karolherbst: but...
12:41 karolherbst: nir allows you to lower a loooot of instructions
12:41 FL4SHK[m]: neat
12:41 zamundaaa[m]: karolherbst: the "triple buffering" I implemented achieves that on even older processors
12:41 karolherbst: ah nice
12:41 Company: zamundaaa[m]: it's gonna be a fun place, because pinephone and librem5 are right at the edge of "too bad to support this"
12:42 FL4SHK[m]: uis: It was not that hard since I designed the instruction set to be easier to write a GCC backend for
12:42 karolherbst: currently on gnome though, but I might even stretch it a little by not having just one 4K, but two 4K displays 🙃
12:42 FL4SHK[m]: It's on my github
12:42 karolherbst: I have nobody else besides me to blame for expecting this to run smoothly :D
12:42 pq: zamundaaa[m], where does your blending difference on SDR vs. HDR come from?
12:43 zamundaaa[m]: Company: that's why I want gamma 2.2. It means that we don't have any additional computations un such low end devices
12:43 FL4SHK[m]: uis: search for flare32 gcc backend on my github, username fl4shk
12:43 FL4SHK[m]: I don't have the link handy right now
12:43 Calandracas: the iGPU on my i9 149000k struggles to drive two 4k monitors :P
12:43 karolherbst: damn users
12:43 zamundaaa[m]: pq: blending with color management (HDR / ICC profile / EDID profile / fallback path for night light) is linear, without it it's gamma 2.2
12:43 karolherbst: shouldn't get 4K displays
12:44 pq: zamundaaa[m], I thought you'd do CM on both?
12:44 FL4SHK[m]: uis: and if you want to check out the instruction set, see flare32_cpu on my github
12:44 FL4SHK[m]: I also wrote a Binutils port
12:44 Company: karolherbst: it's better than Windows, so for now it's good enough
12:44 FL4SHK[m]: the CPU's FPGA code isn't complete
12:44 karolherbst: yeah, the performance is terrible, just noticebly laggy in a few cases, e.g. when animations happen
12:45 karolherbst: *isn't
12:45 FL4SHK[m]: Neat, have fun
12:45 zamundaaa[m]: pq: sort of, it does do color space and TF conversions in the shader if necessary, but it doesn't use the shadow buffer without any color management features enabled on the screen
12:45 zamundaaa[m]: I really really wanted to change that, but the terrible performance of the FP16 shadow buffer on especially older GPUs stopped that
12:46 pq: zamundaaa[m], hmm, but do you have HDR where FP16 sucks?
12:46 Calandracas: turning an FPGA into a subleq machine sounds pretty easy
12:46 zamundaaa[m]: No, but we'd need the shadow buffer for linear blending on SDR screens too
12:47 pq: zamundaaa[m], I'm thinking, if any output is HDR or otherwise needs CM at all, then turn CM on for everything. What's the problem doing that?
12:47 Company: karolherbst: I think the biggest problem in the desktop stacks is that there's no good GPU paths through the whole stack yet, so you end up copying too much at the interfaces between different APIs.
12:47 FL4SHK[m]: Calandracas: yes, it's easy to do something like that
12:47 karolherbst: Company: yeah...
12:47 Company: karolherbst: which makes everything look way worse than it should be
12:47 FL4SHK[m]: but you can go farther than that
12:47 karolherbst: it especially shows when doing screencasting, which... just doesn't work with 4K on my system
12:47 Calandracas: lol ik
12:48 Calandracas: i wrote a subleq machine with MMIO in about 50 lines of lua
12:48 Company: I should play with that with the newest pipewire/gtk/mutter/etc stuff
12:48 karolherbst: I also wished we'd have a better story for prime and drivers accepting foreign non linear images by just detiling with shaders on demand or something.
12:49 zamundaaa[m]: pq: the problem is that all the apps and theming need to be designed for one form of blending. Our logout screen has badly readable text with linear blending for example, and the background opacity slider in Konsole is made for gamma 2.2 blending and confuses users when 90% opacity looks like 50%
12:49 Company: I think that needs a proper library
12:49 Company: some libdmabuf or so
12:49 karolherbst: yeah...
12:49 Company: no idea who'd get that pushed to all the important tools though
12:49 karolherbst: need to write software emulation for tiling and detiling, or declare tiling formats and have code generated or something like that
12:50 karolherbst: oh well.. if we'd just had 100 people more for doing random things like that 🙃
12:50 FL4SHK[m]: uis: honestly I don't know the answer to that question
12:50 pq: zamundaaa[m], I see.
12:51 Calandracas: zamundaaa[m], are there any good colour managed compositors? my solution to having a colour managed workflow was "buy a monitor which doens't need calibrating"
12:51 karolherbst: oh btw
12:51 karolherbst: uis can't be seen on this side
12:51 FL4SHK[m]: oh
12:51 karolherbst: matrix moment
12:51 pq: zamundaaa, sounds like a lot more blending off-loaded to the compositor than I expected.
12:51 FL4SHK[m]: huh
12:51 FL4SHK[m]: Well at least I can be seen
12:51 karolherbst: or maybe something else? dunno honestly :)
12:51 FL4SHK[m]: I'm using Matrix
12:52 Company: it's a matrix thing
12:52 zamundaaa[m]: Calandracas: KWin is a good color managed compositor. Still lots to do ofc, like this blending annoyance, but it works really well already :)
12:52 Company: the bridge sometimes decides to break and not forward some people
12:52 FL4SHK[m]: I do have a machine that I had set up as an IRC client box about half a year ago
12:52 FL4SHK[m]: hmm
12:52 Company: rejoining usually fixes it for affected people
12:52 Calandracas: hum i might consider trying it out. I like sway but having "proper" colour managment would be nice
12:52 Company: *rejoining the matrix channel
12:52 Calandracas: also weston i guess
12:53 zamundaaa[m]: pq: it's exclusively background transparency, but that's used a lot
12:53 Company: at least that was how it was when libera hand't kicked the bridge yet
12:53 FL4SHK[m]: uis just rejoined
12:53 uis: Because IRC server doesn't count my matrix account as logged in
12:53 pq: zamundaaa[m], aha, yeah.
12:53 Calandracas:tries to write his own weston plugin to make it actually useable as a desktop
12:53 uis: And dri-devel is logged-in only
12:53 karolherbst: I wished users would get some kind of feedback when that happens
12:54 uis: I think this is channel settings thing
12:54 FL4SHK[m]: uis @_oftc_uis:matrix.org: so I wrote my software renderer so I could learn how the fixed function parts of 3D renderers/GPUs work
12:54 karolherbst: it's bad enought that apparently on the matrix side people can remain even though they aren't on the IRC side of things
12:54 FL4SHK[m]: that's unfortunate
12:54 FL4SHK[m]: uis is saying it's because dri-devel is logged in only on the IRC side
12:54 karolherbst: uis: well it's not really. It's a matrix (client/bridge/whatever) bug
12:54 FL4SHK[m]: I'm logged in on the IRC side
12:55 FL4SHK[m]: So I can be seen
12:55 FL4SHK[m]: oh
12:55 FL4SHK[m]:uploaded a video: (1499KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/FMyzzgTVAAnGhFOkCXUDlTXK/1000006524.mp4 >
12:55 FL4SHK[m]: I am unsure if this can be seen on the IRC side
12:55 uis: karolherbst: I am on IRC side as uis[m], but IRC thinks I am guest
12:55 karolherbst: yeah.. and the matrix stuff has to cope with the fact a channel is logged in only and prevent people to post messages if they aren't permitted (by whatever means) on the IRC channel
12:55 FL4SHK[m]: Gotcha
12:56 uis: Look, here I write as logged in user(not from matrix)
12:56 karolherbst: sure
12:57 uis: And I wrote from matrix. But you didn't see.
12:57 karolherbst: but you shouldn't be able to join on the matrix side if you aren't registered with your matrix identity
12:57 uis: I'll try to logout from nickserv and write again.
12:57 karolherbst: (or at least get some kind of error)
12:57 karolherbst: anyway...
12:59 uis: I wrote test as uistest
13:00 uis: And you didn't see it too.
13:00 karolherbst: yeah, but you got an error, no?
13:00 f_: I didn't see it either
13:01 uis: No
13:01 karolherbst: I get this: "== #dri-devel Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify)"
13:01 uis: It showed message in channel for me, but not for rest
13:01 uis: Ah, yes. Not in channel though.
13:01 f_: :kinetic.oftc.net 415 funderscore1 #dri-devel :Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify)
13:02 f_: uis: That's on matrix right?
13:02 f_: I'm pretty sure the Matrix bridge just ignores those errors and doesn't return anything.
13:02 f_: Either that, or mutes the channel completly.
13:02 f_: Let me check.
13:02 uis: f_: matrix doesn't show it for me
13:03 uis: The thing is when I log in on matrix and join channel, for IRC I am guest
13:03 karolherbst: yeah.. it's really annoying, because I've heard it has caused severe misunderstandings in the past...
13:03 f_: uis: ok it doesn't return anything, as expected.. The bridge isn't that great..
13:05 f_: But IRC clients should return something.
13:05 f_: Let me check
13:06 f_: uis: > Error (code 415): #dri-devel Cannot send to channel (You are not registered and verified. '/msg NickServ help' to learn how to register and verify)
13:06 Company: hrm, can GL remap a texture? Like, can I use the same mekmory with GL_RGB and GL_SRGB somehow?
13:07 uis: Yes
13:07 f_: Am using senpai as my irc client along with soju bouncer
13:07 uis: f_: yes
13:07 uis: Not to Company's question
13:11 pq: Company, isn't there a toggle to turn the SRGB processing on and off? IIRC there were awfully many bits to get right, before the processing actually happens.
13:12 karolherbst: Company: GL_EXT_texture_sRGB_decode might help?
13:12 zamundaaa[m]: pq: yes, you have to turn the sRGB framebuffer thing on and off
13:12 karolherbst: apparently that's core with 2.1
13:16 Company: it's passed with glTexture2D()
13:16 Company: but then I can't change it later
13:17 pq: the framebuffer thing is a separate toggle
13:20 Company: yeah
13:20 Company: I was thinking about regular textures now
13:21 Company: sry, I should have made that clear
13:21 Company: I was thinking about apps passing GL textures to GTK for rendering
13:21 Company: and those come in as GL_RGB
13:21 karolherbst: GL_EXT_texture_sRGB_decode should let you sample an sRGB texture as linear
13:22 karolherbst: and it's just a property on the sampler
13:22 karolherbst: ehh I mean read out the content directly
13:23 karolherbst: undecoded
13:23 karolherbst: but not sure if that helps in your use case
13:23 Company: oh, that's a sampler parameter
13:23 karolherbst: yeah
13:24 Company: does Vulkan have that step?
13:24 Company: because I only found the srgb format stuff so far
13:25 Company: "If image was created with the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT flag, and if the format of the image is not multi-planar, format can be different from the image’s format"
13:26 Company: I suppose I can just create an srgb vkImageView?
13:28 vsyrjala: wasn't it so that vulkan only has the srgb formats for 8bpc but not for eg. 10bpc?
13:30 Company: yes
14:14 FL4SHK[m]: what is bpc short for?
14:14 FL4SHK[m]: bits per channel perhaps?
14:14 FL4SHK[m]: per RGB channel I guess
14:15 FL4SHK[m]: 24-bit RGB
14:37 FL4SHK[m]: Also I have a question: is there a list of IR instructions that I can look at so I can tailor my ISA to Mesa (to make writing the Mesa backend easier)
14:37 FL4SHK[m]: That's the process I went with to make development of my GCC backend easier
14:46 bl4ckb0ne: does vulkan offer a way to query the extensions enabled on an existing instance/device ?
14:52 pepp: silly question around vblank events: if the compositor commits a new state, it will be visible on screen after 1) flip event/fence is signaled *and* 2) the next vblank event after that... is that about right?
14:52 pepp: (ignoring the delay introduced by the display hardware)
14:54 MrCooper: pepp: the timestamp in the flip / atomic commit completion event corresponds to when the HW starts scanning out the new FB / using the new state
14:56 pepp: MrCooper: oh ok. So I can ignore the vblank (tracepoint) event
14:57 MrCooper: yes; note that events may be sent out earlier than that timestamp
15:08 pepp: MrCooper: thx. AFAICT the flip event is sent by drm_crtc_send_vblank_event
15:09 MrCooper: sounds right
16:18 mattst88: FL4SHK[m]: nir_opcodes.py is probably your best bet
16:18 FL4SHK[m]: mattst88: thanks
18:14 Venemo: DavidHeidelberg: ping. I now managed to build ANGLE but I can't figure out how to make the GL CTS use it
18:14 Venemo: DavidHeidelberg: can you help pls?
18:24 Venemo: DavidHeidelberg: I've tried both LD_LIBRARY_PATH and LD_PRELOAD, but the GL CTS is still somehow searching for RadeonSI
18:40 Venemo: I don't see how it could possibly work, considering that ANGLE only has a libEGL and libGLESv2, so... how the hell is it supposed to work with deqp, which is linked to libGL and libGLX (but not to libEGL or libGLESv2)
18:53 Venemo: I don't even understand why deqp-gles31 is linked to libGLX when I set DEQP_SUPPORT_GLX=OFF
19:25 mattst88: Venemo: I think I have some notes on this from anholt. let me find them
19:25 mattst88: https://chromium.googlesource.com/angle/angle.git/+/HEAD/doc/DevSetup.md is the first thing
19:27 mattst88: Venemo: https://gist.github.com/mattst88/df05dced27f66e16464881c5a5e3c667
19:28 mattst88: I think specifically the thing you need is
19:28 mattst88: > Change src/tests/perf_tests/ANGLEPerfTest.cpp ModuleDir references to SystemDir, so that you can use LD_LIBRARY_PATH to switch to Mesa or switch which Mesa is used.
19:30 dj-death: Venemo: I usually just run the gtest binaries : ./angle_deqp_gl46_tests
19:47 Venemo: thx
19:48 Venemo: dj-death: the gtest binaries are not going to cut it, I have a radv regression that only affects the glcts with angle
19:48 Venemo: mattst88: I already found that, this is not helpful
19:50 mattst88: well, sorry then
19:52 Venemo: mattst88: the trouble is, I already managed to build angle, but the gl cts isn't picking it up even if I specify LD_LIBRARY_PATH or LD_PRELOAD
19:52 dj-death: Venemo: I thought they ran the cts
19:52 Venemo: dj-death: really? I didn't realize that
19:52 dj-death: yeah
19:52 dj-death: there are gles2/gles3/gles31 version etc...
19:53 dj-death: I was stuck like you
19:53 dj-death: I think you need your app to link against angle
19:53 dj-death: there is no way around it afaict
19:53 dj-death: which is why they have those gtest cts variants in there I suppose
20:03 Venemo: dj-death: how do you run a specific test case with those ones then?
20:05 dj-death: --gtest_filter=
20:05 dj-death: you might need some * to figure the actual prefix added by the gtest wrapping
20:07 Venemo: dj-death: ./run_angle_deqp_gles31_tests gives me this: /usr/bin/env: ‘vpython3’: No such file or directory
20:12 dj-death: Venemo: I run the binary directly from the out/Release|Debug directory
20:13 dj-death: Venemo: ./angle_deqp_gl46_tests --gtest_filter=KHR-GL46.shader_image_size.advanced-ms-tes-int
20:13 Venemo: dj-death: same error regardless of where I run it from
20:13 Venemo: what the hell is vpython3
20:13 dj-death: the virtual env thing for python
20:14 dj-death: $ which vpython3
20:14 dj-death: /home/djdeath/src/depot_tools/vpython3
20:14 dj-death: of course
20:14 Venemo: ah the depot tools thing
20:14 Venemo: okay
20:14 Venemo: with that, I get: Failed to start Xvfb or Openbox: [Errno 2] No such file or directory: 'Xvfb'
20:14 dj-death: I don't have that installed
20:15 dj-death: but it's odd
20:15 dj-death: is angle_deqp_gl46_tests not a binary for you?
20:15 Venemo: I don't care about the GL 4.6 tests, I have an issue with GLES 3.1
20:16 Venemo: hence, run_angle_deqp_gles31_tests is what I need, I think
20:16 dj-death: yeah for me it's in cd out/Debug; ./angle_deqp_gles31_tests
20:17 dj-death: it's just binary that doesn't seem to pull in any python env
20:17 Venemo: for me the same is in out/Debug/bin
20:17 Venemo: okay I think I got it, I just had to install some dependencies
20:18 dj-death: Venemo: ah same problem indeed
20:18 dj-death: but yeah I just don't care and run the binary in the directory above
20:21 Venemo: now it gets a bunch of EGL errors
20:21 Venemo: this is a nightmare
20:23 Venemo: Exception running test: Got EGL_BAD_MATCH: eglCreatePlatformWindowSurfaceEXT() at egluUtil.cpp:362
20:46 Venemo: also there is this in the terminal: vulkan: No DRI3 support detected - required for presentation
22:59 mareko: can somebody run all jobs for this pipeline? https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/1201720
23:00 mareko: assigning to marge and unassigning might do it