08:06 HdkR: jekstrand: Kayden: Reproduced the alacritty hang on a version of alacritty with their depth and stencil usage removed. Updated the issue with the latest hang error file
08:10 HdkR: Only 5.5 hours to repro this time
10:27 shadeslayer: tanty: ping :)
10:27 shadeslayer: tanty: I was wondering if you had a minute to talk about how authentication would work for the non-redistributable traces?
11:02 mlankhorst_: robclark: what happened to setting new_crtc_state to NULL patch?
12:07 tanty: shadeslayer: sorry, I was away
12:07 tanty: I have some minutes now
12:08 shadeslayer: tanty: hey hey, so I was wondering, have you tested whether your approach for the non redistributable traces works when the repo is private?
12:09 tanty: we have not gone that much into it, TBH
12:09 tanty: what we have done until now is that "private" is only in the sense of "in a private local network"
12:09 tanty: so, we have not use authentication, although we have a template to add the authentication
12:10 tanty: since the runners would be in the same section of the local private network and the description file for the traces is also in a repo in that same private network section, we didn't need any more auth than knowing that the network is not reachable from outside
12:11 tanty: we didn't want to invest more time into the auth problem before knowing which way we would be going with the community
12:12 tanty: I thought your deployment token was a good idea
12:13 tanty: Are you having problems with that?
12:16 shadeslayer: tanty: yeah, I really like the token idea, but for some reason, it works locally on my machine, but not on the runner
12:18 shadeslayer: tanty: though here's the problem, we're using the git lfs API to fetch the objects, and the CI token does not work with that, instead, it uses it's own authentication token, so we'd have to clone the entire repo locally
12:18 tanty: puff
12:20 tanty: What about using the approach of delegating this to the runners?
12:20 shadeslayer: tanty: pfff indeed :)
12:20 tanty: It'd be something similar to the current approach we are doing.
12:20 shadeslayer: tanty: I'm not sure what you mean by delegating this to runners?
12:20 tanty: Since they are non distributable I'm assuming you would be using specific runners, right?
12:21 tanty: Not letting the public runners from the pool to take those jobs.
12:21 shadeslayer: tanty: ahh, I'm not sure that's something we're concerned about tbh
12:21 shadeslayer: tomeu: ^^
12:21 tanty: If you control de runner, you can manage the setting of it: have the traces NFS mounted, for example
12:22 tanty: or, as we were considering, just having the traces repo in a public gitlab project but in a private section of the network only accessible to those runners
12:22 shadeslayer: tanty: where would this public gitlab project reside though?
12:23 tanty: this is just a picture, not how it may be in the end, since I don't have all the answers (shrugs)
12:23 tanty: but, let's say
12:24 tanty: https://gitlab.local.radv.laboratory
12:24 tanty: this is something in the fashion 192.168.x.x
12:24 shadeslayer: yeah, we're trying to figure it out ourselves too, so it's great to trade ideas :)
12:24 tanty: so, a private section of the network in which the lab is
12:24 shadeslayer: tanty: right, but then this repo isn't accessible to mesa contributors?
12:24 tanty: the repo is only the traces
12:24 tanty: so, no
12:25 tanty: we would have to provide a way of getting individual traces
12:25 shadeslayer: tanty: so to rewind a little bit, is having non-redistributable traces on a public runner a concern for you?
12:25 tanty: when a contributor needs it to debug a failing test
12:26 tanty: shadeslayer: I cannot really answer that since I'm not the one that decies, but I would assume that yes, it will be a problem
12:27 tanty: but, in any case, I don't see how for a specific case we would be able to use a public runner
12:27 tanty: since we are targetting a specific arch and gen of AMD
12:27 tanty: we will have to provide the machines already ourselves
12:27 shadeslayer: I see
12:28 tanty: but, yeah, if we provide (hypothetically) 5 POLARIS10 boards
12:28 tanty: if there is 1 public POLARIS10 board in the pool, we won't be using it for replaying the traces, I believe
12:29 tanty: only the 5 POLARIS10 that we provide
12:29 shadeslayer: I see, so you specifically want a job that's tied to this particular runner?
12:29 tanty: yes
12:29 tanty: if you see the example of the MR
12:30 tanty: I added the tag "valve-mesa-gitlab-ci-private" for the replaying job
12:30 tanty: and only our boards will have that tag
12:31 tanty: FWIW, if, by mistake, a board is added with that tag to the public pool
12:31 shadeslayer: right, I'm just trying to get more details so I can understand what our constraints and objectives are :)
12:31 tanty: the replay will fail since it won't be able to reach the traces
12:32 shadeslayer: right :)
12:32 tanty: yes, I think it is a good idea to try to sync
12:33 shadeslayer: right, I've been trying out approaches with only half a picture in mind, so this is great :)
12:33 tanty: we also have the goal in the future of having performance regression testing
12:34 tanty: for that, not only the board will have to be a POLARIS10, but we will have to make sure that the rest of the HW conditions are the same to be able to test against historical data
12:34 tanty: so, it is important to have control over the HW of the actual runner picking up the job
12:34 tanty: otherwise, the comparison is useless
12:35 tanty: HW *and* SW conditions
12:35 tanty: or, in other words, that the gitlab-runner is set up in the same way too
12:53 tomeu: tanty: shadeslayer: IANAL and haven't read any specific game's license, but I don't see why the license would forbid hosting traces by a third party
12:56 tomeu: non-released games would be made available (if at all) under agreements that would specify security measures so it's not leaked, but I don't think that's a scenario we need to take into account for upstream testing
13:25 jekstrand: HdkR: Ok, cool. Thanks!
13:40 tanty: tomeu: what about the copyright of textures, for example ?
13:40 tanty: just talking from my ignorance ...
13:40 tomeu: well, you aren't distributing them
13:40 tanty: but you are making them publicly available (?)
13:41 tomeu: the traces would be in a protected gitlab repo
13:41 tomeu: it's just that the public runner has a key to access them
13:42 tanty: yeah, I don't know how big of a problem would that be
13:42 tanty: maybe not at all
13:42 tomeu: I guess there's a minimum one needs to do to protect their private data so it's not considered public distribution
13:42 tanty: in any case, as said, I think if only for the practical reason of having control over the HW for comparison reasons
13:42 tanty: you may be right
13:43 tanty: thanks for the feedback, BTW
13:43 tomeu: ah, we use lava, so the envirnment where tests are ran is pristine and uninfluenced by any other tests that may be run in other devices
13:43 tomeu: yw!
13:44 tomeu: well, reasonably pristine, as if it's too warm then thermal throttling could kick in :)
13:44 tanty: :D
15:14 tjaalton: is there a place where lima hackers live, if not here?
15:16 vsyrjala: peru?
15:18 tjaalton: :)
15:18 tjaalton: the gpu
15:27 linkmauve: anarsoul, ↑
15:31 rellla: tjaalton: #lima
15:33 rellla: but afaik everybody idles here as well
15:35 tjaalton: ok thanks
15:36 tjaalton: guess I'll try there first
15:36 anarsoul: linkmauve: ?
15:39 tjaalton: anarsoul: see #lima
19:37 alyssa: anholt`: is arm64_a530_gles3 ok?
19:37 alyssa: (https://gitlab.freedesktop.org/alyssa/mesa/-/jobs/2652653)
19:39 kisak: looks like an unexpected power on reset occured?
19:45 alyssa: Should I restart the job then?
19:53 kisak: I would in your shoes, or re-assign to marge for the same effect
19:57 TD-Linux: does amd hardware have any feature to support pixel doubled and pixel quadrupled modes? for example the low resolution 720x240 HDMI CEA modes
19:58 TD-Linux: an example of hardware that does this is the raspberry pi. looking in the kernel driver for amdgpu, I don't see anything. there are the vsx/vsy scaling parameters that could be used to emulate this, I suppose
20:03 Kayden: dschuermann, pendingchaos: hi! I was about to open an MR with Jason's patch to put 'divergent' on SSA values, when he remembered that you were already doing that. What's the status of MR 4062?
20:04 Kayden: dschuermann, pendingchaos: it looks like there's a bunch of discussion about sanitize_if on radv - it used to use divergence info there, but pendingchaos deleted that in 8dd6a51...
20:04 Kayden: err in aco, not radv
20:09 pendingchaos: I think I got distracted with other things when looking at !4062
20:10 pendingchaos: IIRC the MR looked good though
20:11 pendingchaos: I think the "if (!nir_src_is_divergent(nif->condition))" can be removed when rebasing "nir: Make "divergent" a property of an SSA value"
20:19 dschuermann: Kayden: the MR just needs review, otherwise it should be fine
20:21 dschuermann: Kayden: do you want the first patch in a separate MR? I can rebase it if desired
20:26 Kayden: nah, that's fine. do you want to rebase it? I can give it a review
20:27 Kayden: I had thrown together https://gitlab.freedesktop.org/kwg/mesa/-/commits/ibc-nir this morning, and retyped the ACO changes
20:27 jekstrand: dschuermann: I'm reviewing !4062 now, finally.
20:27 Kayden: but it looks like you've got some other nice improvements in there
20:39 jekstrand: I think something's wrong with gitlab....
20:39 jekstrand: My comments aren't landing.
20:39 karolherbst: jekstrand: change the view :p
20:40 karolherbst: they disappear in the commit diff view or so
20:40 jekstrand: Ok, now it's working.
20:40 jekstrand: I logged out and back in
20:41 karolherbst: ehh, interesting
20:42 EdB: hello jvesely. Don't you think you could find time to review https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/271
20:53 blackhole: hello is there someone who can help with osmesa?
20:53 anholt: not really. note that if you're using the gallium version it's got many bugs
20:53 blackhole: I have an application that is using mesa, the only thing I did for that was to load opengl32.dll compiled by mesa, now I am trying to use osmesa, I have osmesa.dll but renaming osmesa.dll to opengl32.dll & replacing the earlier doesn't seems to work
20:53 blackhole: anholt, I am using swart version
20:53 airlied: osmesa doesn't work like that
20:53 airlied: apps have to choose to use it
20:54 blackhole: airlied, hmm, so the only way is to compile my 3rd party library with it?
20:54 blackhole: Its not binary compatible with opengl32.dll ?
20:54 airlied: it's not a GL dropin replacement
20:54 blackhole: hmm, that's what my analysis pointed as well to
20:55 blackhole: so the only way is to link against osmesa.lib etc?
20:55 blackhole: or is there a way I can create some shim that can act like GL dropin replacement but use osmesa internally ?
20:55 mareko: instead of glBegin, you have to use osmesaBegin or something like that, no?
20:55 airlied: blackhole: I think you are asking the wrong questsions
20:56 airlied: take a step back and state the problem you have
20:56 airlied: it's likely you just want to build mesa into opengl32.dll
20:56 airlied: which I think is another gallium option
20:57 airlied: mareko: I think it provides a GL API
20:57 airlied: but not ther other bits
20:57 airlied: like window system integration
20:57 blackhole: airlied, so what I have is an app that uses openscenegraph, I supported use of mesa by simply building mesa and loading opengl32.dll produced by mesa built. This worked perfectly
20:57 blackhole: but now I needed a solution which uses osmesa (for some reason)
20:57 airlied: blackhole: cool, okay so that works
20:57 blackhole: and that drop in idea didn't worked at all
20:58 airlied: why do you need an osmesa solution?
20:58 airlied: mesa opengl32.dll is the same code
20:58 dschuermann: jekstrand: rumors say, phi is a greek letter as well ;)
20:58 airlied: osmesa is just a different way of accessing it without going through the window system APIS
20:58 jekstrand: dschuermann: Yes, but it has a well-understood meaning in compilers. Mu, gamma, and whatever the third one is, less so.
21:00 blackhole: airlied, so mesa needs X11 which is what I don't want to use
21:00 airlied: blackhole: on windows it shouldn't
21:01 EdB: does marge bot add the RB tag and try to merge a MR if I assign it to her ?
21:01 blackhole: airlied, yeh this was required mainly for mac
21:01 blackhole: airlied, I was just trying also on windows
21:01 airlied: okay I don't think we have any way to build a MAC OS compatible GL
21:01 Sachiel: EdB: no, you need to add the r-b tags yourself, then assign to marge-bot
21:01 airlied: with OSX bindings
21:01 blackhole: airlied, but OSmesa works on mac
21:02 EdB: thanks Sachiel
21:02 blackhole: airlied, and that is why I was planning to do some drop in replacement of osmesa on mac
21:02 robclark: EdB: no.. for freedreno stuff we just decided to not worry about the r-b tags, since stuff marge merges will have a link back to the MR
21:02 airlied: blackhole: okay so then your options are explicitly support osmesa in your app, or figure out how to make macosx work without x11
21:03 airlied: I'm sure the latter is possible using some carbon apis, but I've no actual idea
21:03 EdB: ok thanks, I guess other mesa parts like to have the RB :)
21:03 blackhole: airlied, so you are suggesting make mesa work without X11 ?
21:04 airlied: you'd have to implement whatever window system bidning Apple has (AGL?)
21:04 airlied: and figure out how to drop in mesa instead if possible
21:04 blackhole: I see
21:05 blackhole: airlied, wouldn't that means I will have to change some code in mesa that requires me to build with x11?
21:05 airlied: (NSOpenGL*)
21:06 airlied: you'd haveto change a lot of code in mesa :-P
21:06 blackhole: airlied, actually one the reason I am doing this is to not use Mac's opengl layer, since that might go away
21:06 blackhole: airlied, and that is why I thought I could use osmesa and be done with it ;)
21:09 airlied: blackhole: yeah using osmesa isnt a bad idea, you just need the app to explicitly use it
21:10 blackhole: airlied, hmm yeh..
21:22 jvesely: EdB: I'm really low on time until may 27. I'll try to take a look sooner, but I can't make any promises
21:23 EdB: jvesely: ok, thanks :)
21:42 EdB: pmoreau: test_conformance/api/test_api: FAILED 1 of 76 tests.
21:42 EdB: that pretty nice :)
21:44 EdB: "kernel_required_group_size": "fail"
23:04 ncharlie: hey folks -- I'm trying to debug an issue with AMDGPU, and i'm not sure if it's an issue in the kernel driver or in the user space
23:05 ncharlie: when an invalid register is accessed in the command stream, should mesa filter it out, or should it be sent back to the DRM driver?
23:06 airlied: ncharlie: mesa doesn't filter thing, but if an invalid register is accessed mesa shouldn't never have generated the access in the first place
23:08 ncharlie: airlied, ok thanks -- so that narrows it down to an issue in mesa then
23:08 ncharlie: assuming it wasn't though, would it be expected that the DRM driver crash from one bad instruction?
23:08 ncharlie: on the CPU side, if a segfault or invalid instruction fault gets generated, it's not like the kernel panics, it just kills the process and moves on...
23:09 ncharlie: so I'm trying to understand the expected behavior of the GPU
23:09 kisak: in a perfect world, the kernel would detect the fault and do a gpu reset, but that's less than trustworthy right now
23:09 airlied: mcgrof: have you a dmesg of the crash?
23:10 airlied: it's unlikely what you are seeing is that simple
23:10 airlied: oops
23:10 airlied: ncharlie: ^
23:10 airlied: mcgrof: sorry
23:10 ncharlie: kisak, is that an issue with most drivers or is it a known problem with amdgpu?
23:10 ncharlie: airlied, oh sure -- one second
23:12 ncharlie: here's the dmesg: https://pastebin.com/raw/D4ut8J6v
23:12 ncharlie: (i threw some other dump messages in there)
23:13 ncharlie: so after the initial invalid instruction access it gets stuck in a reset loop, tries 2 times, then just freezes
23:13 airlied: ncharlie: so nothing before the illegal register access?
23:14 kisak: ncharlie: historically the focus has always been to just fix the issues that cause crashes, it hasn't been until vulkan went into regular use in the wild that being able to recover the hardware became manditory in practice. (because vulkan intentially doesn't validate everything going to the video card)
23:14 ncharlie: if I try to force another reset through the debugfs interface, a mutex_unlock call crashes with a NULL pointer dereference somewhere (i'm guessing due to deadlock somehow), but that's unrelated to the current issue
23:14 airlied: ncharlie: it's likely some sort of memory ccorruption by the app you are testing
23:14 airlied: that is corrupting the command stream
23:14 airlied: mesa by itself doesn't tend to cerate illegal command streams
23:14 airlied: it's not unheard off just very far down the likely scale
23:15 ncharlie: airlied, yeah, nothing in the dmesg before the illegal register access -- it's crashing because of an opengl program I wrote :P
23:15 airlied: valgrind maybe
23:15 ncharlie: ok -- would i run valgrind on my program or on the mesa libraries somehow?
23:16 airlied: it'll run on both
23:16 airlied: if you run it on the program
23:17 ncharlie: ok cool -- I'll give that a shot, thanks
23:19 haigedkinomehed: Not that only airlied is a enough solid guy I madly like irish overall even though it hurts how they treat me sometimes, and same goes to russians they talk that Putin is a cunt but Putin is a wonderful guy, a native russian who thinks that not all the world belongs to zionists. It really will be going to hurt when conflicts like that take place, where native russians germans dutch english irish and alike or so will be violated by say
23:19 haigedkinomehed: someone like zionists.