06:44 Kayden: ivyl: I noticed that you committed a change to proton to remove PROTON_DUMP_DEBUG_COMMANDS - any particular reason why that's gone? is there something I should be using instead now?
06:46 ivyl: It's gone because it was not really used by proton devs and was breaking in 9.0. It also runs Proton outside of the Steam Runtime which is not supported and breaks on a lot of systems. https://github.com/ValveSoftware/Proton/blob/experimental_9.0/docs/DEBUGGING.md
06:47 Kayden: ah, okay. I just used /tmp/proton_$USER/run to run executables in there a lot
06:47 Kayden: in case I wanted to run other programs in the same prefix
06:48 ivyl: There are some tips on the new debugging mechanisms that involve SRT. Also you can use `PRESSURE_VESSEL_SHELL=instead %command%`. This will spawn xterm inside srt and the Proton invocations should be in $@
06:50 ivyl: For that `PRESSURE_VESSEL_SHELL=instead %command%` is bests IMO. Then you just `echo $@` which should make it obvious what to use. You want to execute something like `~/.steam/root/steamapps/common/Proton\ -\ Experimental/proton waitforexitandrun path-to-your.exe`
06:50 Kayden: cool, thank you!
06:51 ivyl: this way you end up inside of the SRT environment and have everything that Steam sets... set. Proton script knows what to do with those.
06:52 ivyl: debug commands was an unfortunate leftover from pre-pressure-vessel days where we were just LD_LIBRARY_PATH things. It also depended on us maintaining list of environment variables to dump.
06:52 ivyl: np, happy to help, and thanks for reaching out about this :-)
06:52 ivyl: I'll add a note on this usecase to debugging.md
06:52 Kayden: yeah, that makes sense :)
06:52 Kayden: I figured there was a newer better way
07:31 tzimmermann: sima, airlied, just a friendly reminder for the -rc6 merge
07:31 sima: tzimmermann, I thought I've done it?
07:31 tzimmermann: ok, sorry then
07:32 sima: you weren't on irc anymore, and I forgot to ping you on Tue
07:32 sima: (yesterday was holiday here)
07:32 tzimmermann: yeah, on holiday as well
07:32 sima: I did a bit an oopsie because I didn't noticed that airlied already backmerged -rc5, so the justification isn't entirely correct
07:33 sima: but the defio part still holds, so ok-ish still
07:33 tzimmermann: sima, oops, my mistake. sorry for the noise
07:33 sima: tzimmermann, nah the defio fixes where in -rc6 only, so I think backmerge still needed
07:34 sima: or was that not the fixes you needed?
07:35 tzimmermann: it it
07:36 tzimmermann: i meant, my apoligies for pinging you again after you already did the backmerge. i looked in the wrong place at first
07:52 sima: tzimmermann, ah no worries, I forgot to ping you after all too
08:00 concentration1: so the pseudo code on 10bit conversion routine. The most complex is r300 radeon with no flags for saturation and no bitwise ops. glsl 1.1. So every intermediate result gets lifted to 528 format then summed up.
08:00 concentration1: value; //724 or 300 a=value-512; b=max-value-512; c=value; d=a+b; //212 e=c-d; //88 or 512 g=d+e; // 300 or 724
08:01 concentration1: but this as you see ends up fairly straightforward and easy.
08:08 concentration1: what i think is that scammer estonian leftovers get a concentration camp by armed forces. And to be honest that is how it is suppose to be. Those are world nr1 nonsense terror scammers.
08:09 concentration1: they live my life dark sides, injure me in hospitals and think they get better in performance that way, but leftovers do not advance that way.
08:10 concentration1: but back to the example, it just removes the half of the maximum out of the way, so that magic values can be acomodated
08:10 concentration1: so this would be very think routine to lift and we want to get 64 as the first 2 in power of zero to be represented, and 128 as power of 32-1
08:12 concentration1: it's the equivalent of bitshifting the fields, but in case you do not have those, you can do like this
12:33 zmike: DavidHeidelberg: I'm looking at 9989 now
12:38 zmike: I'm unable to repro dEQP-EGL.functional.choose_config.simple.selection_and_sort.* failures
12:42 zmike: ah maybe because I'm not using a stable branch
12:43 zmike: I'm unsure what the actual problem is at this point
12:44 zmike: seems to me that cts needs to have EGL_EXT_config_select_group backported and that's it
13:13 DemiMarie: Is the reason for the dma-fence rules that GPUs can't take page faults but also don't use pre-pinned memory management?
13:45 dolphin: DemiMarie: That's bit of a long discussion, but in short it's simplicity
13:46 robert_mader: Hi! It is slightly off-topic question regarding dma heaps: does anyone here see a reason why they shouldn't be available to all users or e.g. the `video` group? I.e. would free access to them make it more easy to crash GPU drivers or have other security implications? Right now dma heaps don't seem to have default udev rules and I wonder if they were simply forgotten because of missing users. (context: https://gitlab.alpin
13:46 robert_mader: pine/aports/-/merge_requests/65223).
13:46 dolphin: when you are guaranteed that the wait will complete in reasonable time (aka. user doesn't reach out for the power button yet), you can simplify a lot of coding on the fence waiting side
13:50 bbrezillon: mlankhorst: Hi! I have panthor fixes for drm-misc-next. Given we're passed -rc6, I thought I'd have to push those to drm-misc-next-fixes, but it seems the drm-misc-next -> drm-misc-next-fixes merge didn't happen yet, because I don't see the panthor driver there
13:50 bbrezillon: Can I push those to drm-misc-next?
14:18 mlankhorst: bbrezillon: just push. I can branch from drm/drm-next
14:19 mlankhorst: lets see..
14:21 mlankhorst: or at least I guess that would be the usual way of doing things?
14:30 mripard: mlankhorst: I think bbrezillon point was that he'd like these patches to reach 6.10-rc1
14:30 mripard: not 6.11
14:32 mlankhorst: remote: **The dim tool you are using is outdated, please upgrade.**
14:32 mlankhorst: hmm..
14:32 mlankhorst: did I miss something?
14:35 mripard: that doesn't ring any bell
14:35 mripard: and grep on outdated or upgrade doesn't return anything either
14:35 mripard: can you paste the whole dim output?
14:35 mlankhorst: That's from the remote hook
14:36 mripard: did you push with git directly?
14:37 mlankhorst: ../maintainer-tools/dim push
14:39 mlankhorst: http://paste.debian.net/1315845/
14:39 mripard: so, I guess you missed the migration to gitlab :)
14:40 mripard: run dim ub twice
14:41 mlankhorst: ah, should be less cryptic though
14:42 mripard: yep
14:42 mripard: daniels: ^
14:42 mripard: daniels: back when we did the migration, Ben basically reused the old server hook to decline everyone (but gitlab iirc) to push to the cgit repos
14:43 mripard: could you amend the error message so that it's more obvious that one is pushing to cgit and shouldn't?
14:47 mlankhorst: looks like anyone from drm-misc can change the hook. :p
14:48 mlankhorst: The real problem is coming up with a great error message.
14:50 mlankhorst: ah, rofs
14:50 mlankhorst: I guess one can't
14:53 mlankhorst: bbrezillon: you can push to drm-misc-net-fixes now?
14:58 bbrezillon: mlankhorst: thanks!
14:59 mlankhorst: I'll cherry pick all fixes marked as such from drm-misc-next and then send out a pull request later today
15:26 bbrezillon: mlankhorst: don't wait for my fixes, I might not push them today
15:36 daniels: mlankhorst: if you can please pop a new hook into ~mlankhorst, I'll copy it into all the repos
16:08 mlankhorst: daniels: got one now?
16:08 daniels: root@kemper:/srv/git.freedesktop.org/git/drm/drm-misc.git% ls ~mlankhorst
16:08 daniels: .bash_logout .bashrc .profile .zshrc
16:08 daniels: or do you mean you need a copy of the existing one?
16:09 mlankhorst: I'm on people.freedesktop.org
16:09 mlankhorst: can't ssh into kemper
16:10 daniels: mlankhorst: ok, done now, thanks!
16:14 mlankhorst: remote: You are attempting to push to a mirrored repository.
16:14 mlankhorst: remote: Please push to gitlab instead.
16:14 mlankhorst: remote:
16:14 mlankhorst: remote: Please run "dim ub" a few times to update all branches to
16:14 mlankhorst: remote: their new gitlab locations.
16:14 mlankhorst: much better
16:33 DavidHeidelberg: zmike: I think currently it's another bug GL-CTS, because except sorting tests is green
16:33 DavidHeidelberg: zmike: BTW the patch is backported :)
16:59 zmike: DavidHeidelberg: I tried to figure out what was still an issue but it's impossible
16:59 zmike: there's too many comments
17:02 DavidHeidelberg: zmike: try run it locally (piglit and recent deqp), only the sorting test should fail, nothing else
17:03 DavidHeidelberg: If something else is failing, then we still have problem outside of the tests
17:11 zmike: I'll try again tomorrow
17:53 mripard: daniels, mlankhorst: thanks :)
20:42 mlankhorst: sima, airlied: Can I cherry pick fixes from drm-misc-next and put them in -next-fixes pr?
21:24 sima: mlankhorst, yeah should be fine, maybe check out the dim cherry-pick helper
21:24 sima: minimally needs to reference the commit from -next so that the confusion that git merge tends to create has a clear reason
21:29 mlankhorst: ah I'll try that one