00:50 imirkin: chrisf: anything else i need to do on that VK-GL-CTS thing?
04:03 kode54: what determines the load order for Vulkan ICDs?
04:03 kode54: I see vulkanCapsViewer reports one driver as "GPU0" and another as "GPU1", yet vkcube picks the second one by default
04:04 airlied: kode54: order of files from dirent I suspect
07:25 kode54: airlied: aha
08:00 anarsoul: does anyone have any idea why GLSL_InitGPUShaders in ioq3 may take quite a while? (that's on lima but IIRC I saw similar behavior on panfrost)
08:13 MrCooper: anarsoul: the function name sounds like it might compile shaders?
08:14 anarsoul: MrCooper: yeah
08:14 anarsoul: but lima compiler is not much slower that other compilers (at least according to deqp run time)
08:14 anarsoul: we don't cache compiled shaders yet though
08:14 MrCooper: compiling shaders can take significant time
08:15 MrCooper: anyway, just a guess, better profile it
08:15 anarsoul: yeah, will do
08:15 anarsoul: just wondering if anyone saw it with other drivers
08:20 pq: imirkin, about diffs in gitlab, I have a 'git fetch-mr 351' command to git-fetch the MR !351 as a branch in my local repo so that I can review it. I find it equally painful to read diffs in emails and Gitlab, except in email you cannot load more context for a hunk and you have no idea what the base commit for the patches was so maybe they don't even apply.
08:22 pq: my git-fetch-mr is really just forming a git url to git-fetch from, nothing more,
08:29 MrCooper: pq: I'm just fetching all MRs into <remote>/merge-requests/<number> :)
08:32 pq: MrCooper, I fear that would make my 'gitk' UI a big mess - it's already somewhat a mess with only the MRs I'm actively reviewing in Weston.
08:33 MrCooper: for "big mess" in "can easily see which changes are from which MR", sure :)
08:34 pq: Keeping a local copy of a MR branch from the time I last reviewed it soetimes helps tremenduously to see what changed in a new revision of the MR when it gets updated and rebased.
08:35 MrCooper: that's what the git reflog is for
08:35 pq: I can even rebase the old revision myself and check that the submitter's rebase resulted in the same, letting me easily filter out the upstream changes from the MR changes
08:44 MrCooper: pq: the git reflog allows you to do e.g. git diff <remote>/merge-requests/<number>@{yesterday}..<remote>/merge-requests/<number>
08:49 pq: MrCooper, ok, I never really looked into reflog. But it seems I would have to record somewhere anyway what was the exact revision I looked at last.
08:50 pq: people might push new stuff 15 mins before or after I started to take a look
09:07 kode54: why does ACO disable several extensions? is the memory layout on device not compatible with those extensions when using ACO?
09:07 HdkR: kode54: It doesn't yet support every extension
09:07 kode54: ah
09:08 kode54: seems a certain console emulator makes use of VK_KHR_16bit_storage and VK_KHR_8bit_storage
09:08 HdkR: Yea, Yuzu uses it without a fallback
09:08 HdkR: There is already an issue opened for it, it's on a todo list somewhere :P
09:08 kode54: they're even recommending the use of amdvlk instead of mesa
09:09 kode54: I compared the three with something that actually matters to me
09:09 HdkR: weird, llvm path should support it with radv
09:09 HdkR: Going full tilt to amdvlk seems aggressive
09:09 kode54: there was someone who experienced a total driver crash on llvm
09:09 kode54: as in, system totally locked up, unresponsive even to ssh
09:10 kode54: oh well, I don't really use this thing, just hearing this news
09:10 kode54: I compared the three I care to test (RADV LLVM and ACO, and AMDVLK) on a wine dxvk game
09:11 kode54: amdvlk got the worst of it, at 58fps, while RADV LLVM got 59, and ACO got 68
09:11 kode54: ACO also had way less hitching due to shader compilation
09:11 HdkR: Yea, it works well in that regard
09:11 kode54: in this case, ruddy damn UE4 game running on DX11
09:11 kode54: I wonder if they'll even bother to port it to Linux when it comes to Steam
09:12 kode54: Borderlands 3, running on the Medium preset, 3840x2160 at 50% scale
09:13 kode54: oh well, I care more about that than either getting involved in Yuzu piracy or buying a console for the sole purpose of winning the moddability lottery and using it just to fuel an emulator
09:13 HdkR: Original Switch hardware is unpatchable :P
09:13 kode54: I know
09:14 kode54: but what are my chances of getting a vulnerable system at this point?
09:14 HdkR: Should be decent with 18 million or so of them on the market
09:14 kode54: ah
09:14 kode54: well, I'll consider that
09:15 kode54: I'll have an extra $170 of monthly spending money starting in June, when this shitty payday loan allegedly gets paid off
09:15 Venemo: kode54: out of curiosity, what hardware did you run it on? and did you use amdvlk with the proprietary compiler or llvm?
09:15 kode54: Asus ROG Strix RX 480 O8G
09:15 kode54: I've only had to replace it 3 times, presumably they just baked it and shipped it back to me
09:16 kode54: at $26 a pop for return shipping, they paid its way back to me
09:16 kode54: last time I buy an Asus card
09:16 malice: 3 times? Wow what?
09:17 kode54: yeah, it would randomly glitch sometimes, and then after enough heating and cooling cycles, it would just glitch so badly it would lock up the OS
09:17 kode54: I used to blame the drivers, but I learned it was the hardware
09:17 kode54: RMA'd 3 times, this one's the last I'll get since the warranty finally gave out
09:18 kode54: I hear their Vega and Navi cards were just as big a disaster
09:18 Venemo: ouch.
09:18 kode54: next time, I hope to get one of those Sapphire 5700 XT cards, or maybe I'll settle for a 5600 XT
09:19 kode54: just making sure by the time I get it, the new SMC firmware is in linux-firmware
09:19 Venemo: I haven't had an asus card in a long, long time, but my brother is happily using his 5 year old R9 270X without issued
09:19 Venemo: issues*
09:19 kode54: nice, good
09:19 kode54: may have been an issue because the first card, I kind of ran NiceHash on it for a week, and the second, I kind of did the same for a few hours before I came to my senses
09:20 kode54: the third, which was the second RMA, never did such stupid shit
09:20 kode54: this is the fourth attempt
09:20 Venemo: I have the reference 5700 XT now, which is decent, the only thing that bothers me is the fan noise
09:20 kode54: ah
09:20 kode54: the fan is fairly quiet with this one
09:20 kode54: three fans, going ~900 RPM most of the time
09:21 Venemo: the reference card has a blower cooler
09:21 kode54: ah
09:21 Venemo: the non-reference ones should be just as quiet as any other
09:22 kode54: cripes
09:22 kode54: I can't even fit a fricking 5700 XT
09:22 Venemo: why not?
09:22 kode54: this 11.7 inch card is already in need of maneuvering to fit past the support rail in my case
09:22 dschuermann: kode54: either me or pendingchaos will take care of storage8/16 soon*
09:22 kode54: dschuermann: ah, hi. I see, nice
09:23 kode54: the Nitro+ 5700 XT is 12.1 inches
09:23 Venemo: kode54: there are shorter 5700 XTs than that
09:23 dschuermann: *(we have a couple of urgent bugs to fix for mesa 20.0, first. but then it will probably just be the next task)
09:23 kode54: urgent bugs? that's not good
09:24 Venemo: kode54: the powercolor 5700 XT should definitely fit.
09:24 kode54: I'll just quietly report any issues I can trace already
09:24 dschuermann: well, nothing to bad. just a couple of rendering issues on some games, we would like to get rid of before adding new features
09:26 kode54: right, that's always important
09:27 kode54: fun thing I wanted to try getting someone from winehq to look at, since it may or may not be fun
09:28 kode54: 4700 bytes of .exe that is so particular that it neither runs on wine (nor windows with apitrace hooking it)
09:28 kode54: wonder what idjits managed to do there
09:29 kode54: they also import all functions by using kernel32 to loadlibrary and getprocaddress everything instead of exposing an uncompressed import table
09:29 hakzsam: MrCooper: any ideas what package is missing? it looks like a pain to figure which ones
09:31 MrCooper: haven't looked at it, can you paste the MR URL again?
09:32 hakzsam: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3637
09:32 gitbot: Mesa issue (Merge request) 3637 in mesa "WIP: ac,radv,radeonsi: remove LLVM 8 support" [Ci, Radv, Radeonsi, Opened]
09:39 benjiG: danvet: Hi, does something has changed in dri patchwork ? it doesn't add link tag anymore.
09:44 MrCooper: hakzsam: comparing https://storage.googleapis.com/fdo-gitlab-artifacts/0e/0c/0e0c8d9c5fa46e66bd8293289e410bbc9e35da10a211a4d5c3e0b64a373db54f/2020_02_03/1532825/2315365/job.log?response-content-type=text%2Fplain%3B%20charset%3Dutf-8&response-content-disposition=inline&GoogleAccessId=GOOGOEXJKVLVDILPMJ5V2WSY&Signature=EPE%2FVhc%2B3orfJea2UspyfHXx5oM%3D&Expires=1580809528 to https://storage.googleapis.com/fdo-gitlab-artifacts/cb
09:44 MrCooper: /a2/cba28b89eb859497f544956d64cf2ecf29b76fe2ef7175b33ea59e64293a4461/2020_01_06/1280794/2010582/job.log?response-content-type=text%2Fplain%3B%20charset%3Dutf-8&response-content-disposition=inline&GoogleAccessId=GOOGOEXJKVLVDILPMJ5V2WSY&Signature=WGfClpNaDy7QKiVSotQ9BIAmOW0%3D&Expires=1580809706, the only difference I can spot in the VK-GL-CTS cmake output is that the "egl" version went from 18.3.6 to 1.5 (probably GLVND
09:44 MrCooper: related); could it be related to that?
09:45 benjiG: tzimmermann: you have commited and push a patch yesterday on drm-misc-next, right ? No issue with patchwork to add link tag ?
09:45 hakzsam: MrCooper: no ideas
09:46 tzimmermann: benjiG, which one? if so, this was a mistake
09:46 hakzsam: MrCooper: libglvnd-core-dev?
09:46 MrCooper: what about that?
09:47 benjiG: tzimmermann: the one about putting yourself as maintainer
09:47 benjiG: it had patchwork Link tag inside
09:47 hakzsam: MrCooper: it's installed in the old image but not in the new one
09:48 tzimmermann: benjiG, no sure what you mean. there's a link tag in the patch https://cgit.freedesktop.org/drm/drm-tip/commit/?id=6f21293dbbde5f66788a5645ddea3c567dc02443
09:49 MrCooper: hakzsam: it's not needed anymore, just a transitional dummy package which depends on libglvnd-dev now
09:50 benjiG: tzimmermann: yes the link is suppose to be added by patchwork but that doesn't work on my side
09:51 hakzsam: MrCooper: well, one solution maybe is to force re-building the current arm test image, list the installed packages at the end and compare?
09:51 tzimmermann: benjiG, i still don't get what you mean. copying https://patchwork.freedesktop.org/patch/msgid/20200130120643.5759-1-tzimmermann@suse.de from the patchfile directs me to https://patchwork.freedesktop.org/patch/351256/
09:52 MrCooper: hakzsam: actually, looks like deqp-runner just can't find any of the tests?
09:53 MrCooper: so could be an issue with the build or invocation of that instead of with dEQP itself
09:53 hakzsam: I don't know how this can happen
09:54 tzimmermann: benjiG, btw. the link tag is not added by patchwork, but by dim as part of 'dim apply-branch'
09:57 benjiG: tzimmermann: yeah it seems that my problem is comings form something else
09:57 tzimmermann: benjiG, what are you trying to do? the link tag's url doesn't work for you?
09:58 MrCooper: hakzsam: including the individual results *.xml files in artifacts might give a clue
09:58 benjiG: tzimmermann: jsut try to apply stm patches with dim on drm-misc-next
09:59 benjiG: but git complains about sha1 information
09:59 tzimmermann: benjiG, i suppose you're following https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
10:00 benjiG: tzimmermann: yes I do as usual, update the branches, get patches from patchwork, compile, test and dim push
10:01 tzimmermann: benjiG, after posting he patch on the ML and getting r-bs and a-bs, etc, I save the email from my mail client to disk, and that do "cat <email file> | dim apply-branch drm-misc-next"
10:02 benjiG: tzimmermann: same here
10:02 benjiG: cat ~/Downloads/drm-stm-ltdc-enable-disable-depends-on-encoder.patch | ../maintainer-tools/dim apply-branch drm-misc-next
10:02 MrCooper: hakzsam: since the cmake output is (almost) identical, I don't think it's a missing package
10:02 benjiG: error: sha1 information is lacking or useless (drivers/gpu/drm/stm/ltdc.c).
10:02 tzimmermann: benjiG, from the email's message id (or something else), dim creates the link tag to patchwork.
10:02 hakzsam: MrCooper: okay, I will figure out
10:03 tzimmermann: benji, you have to store the mbox file
10:03 tzimmermann: not the patch, but the mail with the patch
10:04 benjiG: tzimmermann: pacthwork "download mbox" provides the patch ...
10:05 benjiG: same with mbox file
10:06 tzimmermann: benjiG, let me check
10:07 benjiG: I try with this one: https://patchwork.freedesktop.org/series/72293/?_sm_au_=irW88qJPLRQLM0njcLpsvK618Vf61
10:11 airlied: danvet, benjiG, tzimmermann : i had an issue with the last pull I did from patchwork failing to add the link
10:11 tzimmermann: benjiG, you can find my saved file at https://pastebin.com/R2Fdqyw0
10:11 airlied: it printed some wierd diagnostic when I ran the command
10:11 airlied: I was just assumping ot was utf-8 related or somethign
10:12 airlied: I'll try and reproduce tomorrow if nobody has any clues about losting link
10:12 danvet: airlied, which pull?
10:14 benjiG: airlied: I have a utf-8 content-type
10:14 tzimmermann: benjiG, I just tried with the mbox file from patchwork and the link got added
10:15 benjiG: tzimmermann: with the stm patch above ?
10:16 tzimmermann: benjiG, with my patch. i'll check the stm patch as well
10:16 tzimmermann: benjiG, airlied, did you have a conflict during import? i noticed that dim didn't add the link when i had to resolve a conflict
10:16 benjiG: no conflict on my side
10:20 tzimmermann: benjiG, the mbox file from https://patchwork.freedesktop.org/series/72293/?_sm_au_=irW88qJPLRQLM0njcLpsvK618Vf61 is garbage
10:20 jekstrand: ickle, danvet, airlied: How would you feel about a pair of ioctls which let you fetch the dma-fence from a BO as a sync file and let you explicitly "signal" the BO from a sync file?
10:21 tzimmermann: benjiG, wait a sec
10:21 jekstrand: Specifically, I'm looking for something which would let us build a bridge between explicit and implicit sync
10:21 ascent12: jekstrand: I've brought that up myself in the past. It's something I eventually want too.
10:22 ascent12: Apparantly an old patch exists (or would be simple to write) and just needed a real userspace to use it.
10:23 jekstrand: Yeah, it's not hard and I think it can be a generic GEM ioctl rather than having to be driver-specific.
10:23 jekstrand: ascent12: I may have a use for it in the near-ish term for Vulkan.
10:25 tzimmermann: benjiG, i tried the mbox file from https://patchwork.freedesktop.org/patch/349674/?series=72293&rev=1
10:25 tzimmermann: benjiG, git said the SHA-1 is missing
10:25 pq: jekstrand, you want to force a fence to signalled before the action completes? When is that useful?
10:25 tzimmermann: so it doesn't apply the patch
10:26 jekstrand: pq: I want to manage the fence on the dma-buf myself rather than have it be implicit based on execbuf calls.
10:27 pq: jekstrand, that sounds something very different.
10:27 tzimmermann: benjiG, which tree is that patch against?
10:27 jekstrand: pq: The problem is that the current implicit sync stuff doesn't map very well to Vulkan's synchronization model for WSI
10:28 benjiG: tzimmermann: it should be drm-misc-next
10:28 pq: jekstrand, are explicit fences not always causing the implicit fence to be ignored? I thought at least KMS does that.
10:28 tzimmermann: benjiG, that's what I'm applying to
10:29 jekstrand: pq: We currently handle it by ignoring all fences most of the time and then having a new semaphore mode for "WSI BO" where we stuff the BO in the semaphore and use the BO with fencing enabled when the client signals or waits on the semaphore.
10:29 jekstrand: pq: It works ok but it's not great. It's also impossible to tie it in nicely with timeline semaphores.
10:30 pq: okay... way over my head, I really thought the generic principle is "ignore implicit fence if an explicit fence is given", no matter what API.
10:31 jekstrand: pq: Backing up...
10:31 jekstrand: pq: If we have explicit sync, we want to 100% ignore the BO fences
10:31 pq: umm...
10:32 jekstrand: pq: However, if we're on X11 or a compositor that doesn't support the Wayland explicit sync protocol, I'm looking for other options.
10:32 pq: you mean explicit sync != a fence?
10:32 jekstrand: Ok, now I'm confused why you're confused. :-P
10:33 pq: I think around 80% of the terminology you use is foreign to me :-)
10:33 jekstrand: heh
10:34 pq: I only know fences as a generic userspace concept, and that a dmabuf fd carries an implicit fence in it, and the dmabuf fd can be used in place of fence fd if necessary.
10:35 pq: and that userspace passes fences around as fds
10:35 jekstrand: Yeah, each dma-buf has a fence (maybe set of fences?) attached to it implicitly.
10:35 pq: when you say "BO fence", do you mean the implicit fence?
10:36 jekstrand: yes
10:36 pq: ookay
10:37 pq: I suppose you have cases where you cannot tell an API to ignore the implicit fence, so you want to force-signal the fence before it actually completes?
10:37 jekstrand: No
10:38 jekstrand: The way GEM was originally created, every GPU access waited for the BO fence before executing and set the BO fence so any subsequent GPU submissions would wait on that execution.
10:38 jekstrand: This is how we guarantee that weston doesn't start texturing before the app is done rendering.
10:39 benjiG: tzimmermann: it is working with an other patch ...
10:39 pq: Yes.
10:39 jekstrand: With Vulkan, however, we want to disable implicit sync and hever set or check that fence. Instead, the client provides synchronization through the API in terms of what Vulkan calls semaphores.
10:39 danvet: jekstrand, get/set for implicit fences isn't a problem, it's just no one typed it up yet
10:39 danvet: including userspace and tests
10:40 tzimmermann: benjiG, weird. maybe the patchfile is broken
10:40 danvet: wrt what kind of thing you get/set, maybe sync_file
10:40 benjiG: tzimmermann: yes I will look at it later
10:40 danvet: or at least not "new sync pt in timeline syncobj automatically updates any corresponding dma-buf it's linked to"
10:40 jekstrand: pq: What I want is a way to bridge between the two where I leave implicit sync disabled and manually manage the fence on the dma-buf
10:40 pq: jekstrand, sorry for being a rubber duck, not sure you needed one. ;-)
10:40 danvet: cause the locking is all bonkers between these two :-)
10:40 ascent12: I would like a sync_file for that, so when I write my explicit-sync code, legacy implicit-sync buffers can use exactly the same code paths.
10:40 jekstrand: pq: No worries. Always happy to explain things to interested people. :-)
10:41 danvet: not impossible, just "are you sure"
10:41 danvet: ascent12, oh btw did you see my ping about the sway atomic fallback stuff
10:41 danvet: ?
10:41 danvet: specifically about modifiers and all that
10:41 ascent12: danvet: Yeah, I did.
10:41 danvet: I wasn't around when you wanted to reply?
10:41 jekstrand: danvet: The reason why I suggested sync_file is because it's a very direct wrapper around a dma-fence which means that it automatically works for all cases where we can extract or insert a sync_file.
10:42 danvet: jekstrand, oh you suggested sync_file?
10:42 jekstrand: Otherwise, I'd have to have a separate "copy my fence" API for timeline vs. binary syncobjs.
10:42 danvet: I somehow read you're suggesting syncobj
10:43 jekstrand: Also, sync_file means that we have all the normal dma-fence guarantees about finite time completion.
10:43 pq: jekstrand, aha. Timelines and syncobjs tell nothing to me. I thought there was just one kind of fence thing userspace handles.
10:44 ascent12: If I interpret it correctly, a syncobj is a sort of wrapper for a sync file which was needed to give it the correct semantics for vulkan.
10:45 ascent12: And now has a timeline in it.
10:45 danvet: pq, in the kernel it's all dma_fence
10:45 danvet: but we now have different container things for userspace for these
10:45 jekstrand: pq: The most "direct" container is a sync_file which is pretty much 1:1 with dma-fence
10:46 jekstrand: syncobj is a container which holds a dma-fence pointer but it can get swapped out. It's roughly a BO with no data.
10:46 jekstrand: syncobj can also hold timelines of dma-fences
10:46 emersion: danvet, ascent12: what was this atomic/modifiers discussion about?
10:46 jekstrand: dj-death: ^^
10:47 ascent12: danvet: I think I might've forgot to mention your name when I replied, so it didn't ping you. The fallback currently is just fallback to the non-modifier API, but it's planned on being improved.
10:47 pq: I'm afraid this is too many new terms for me to learn from just irc, but thanks for trying. :-)
10:47 emersion: yeah, we'd need to re-allocate buffers for all outputs
10:48 dj-death: jekstrand: yes
10:48 emersion: and maybe prune modifiers
10:48 dj-death: jekstrand: you wanted confirmation? :)
10:48 jekstrand: dj-death: Not that we need more paths for vksemaphore. :P
10:49 jekstrand: dj-death: Mostly wanted to make sure you were reading. :-)
10:49 dj-death: heh yeah
10:49 dj-death: I am
10:49 jekstrand: dj-death: I think this may be a non-terrible plan for timelines + WSI
10:53 dj-death: jekstrand: thinking if we need anything more for wait before signal
10:53 dj-death: jekstrand: maybe a reset capability
10:54 jekstrand: dj-death: Yeah, that's where things get stiky
10:54 jekstrand: dj-death: One option would be a userspace thread for WSI
10:54 jekstrand: Which we already have for most modes
10:56 jekstrand: dj-death: Where it all gets very sticky is MAILBOX because the spec currently guarantees that vkQueuePreset for Wayland does not return util wl_surface::commit has been called.
11:01 dj-death: I think it will be required
11:02 dj-death: because if any of the wait semaphore hasn't materialized, you need to wait for it and i915 won't be able to do the wait
11:02 jekstrand: Yeah
11:03 jekstrand: There are some semantic details to work out there
11:03 dj-death: kind of sucks to have a thread per window...
11:03 jekstrand: yeah, it does
11:09 dj-death: I thought of a way of handling all those submissions with a single thread, but it would be fairly inefficient
11:10 jekstrand: Yeah, you just about need a full-on event loop. :-(
11:10 dj-death: we don't have a way to get drm to tell us what fences on a wait are signaled, just that either one or all have signaled
11:11 dj-death: probably could have added that feature when timelines were added
11:11 jekstrand: Can we combine ALL and READY (as opposed to SIGNALED)?
11:13 dj-death: yes
11:13 jekstrand: dj-death: It is rather annoying if we'd have to merge all of the sync_files together into one
11:13 jekstrand: Hopefully, they're not using a lot of semaphores
11:14 jekstrand: Unless the semantics of the SET_FENCE ioctl is more of an ADD_FENCE which does the combining
11:15 dj-death: actually we could do in 2 ioctl
11:15 dj-death: wait + query
11:16 dj-death: that's not too bad
11:16 jekstrand: I think it'd be 3. wait, query, and SET_FENCE on the BO
11:16 dj-death: yes of course
11:16 jekstrand: If they pass in a pile of VkSemaphores, we'd have to either call the MERGE ioctl to combine them or make SET_FENCE do an implicit combine.
11:17 dj-death: I was thinking about single thread to handle delayed QueueSubmit as well as QueuePresent :)
11:17 jekstrand: I *think* making SET_FENCE do an implicit combine is consistent with how it works in the HW driver.
11:18 jekstrand: dj-death: Yeah... That could get interesting. There is some advantage to what we're doing now because it lets all the WSI code live in a separate plac.
11:18 dj-death: but hey
11:18 dj-death: we still don't have timeline semaphore support in i915...
11:18 jekstrand: Yeah.....
11:19 jekstrand: dj-death: How's that coming?
11:20 jekstrand: dj-death: If we could get the i915 timeline and GET/SET_FENCE in the same kernel version, then we could implement timelines + WSI without a hitch.
11:20 jekstrand: Because we can use the WSI BO in the timeline for the non-shareable implementation.
11:20 dj-death: jekstrand: it's a bit stuck for the timeline, I don't really understand why
11:21 jekstrand: :(
11:21 jekstrand: dj-death: If you want me to send grumpy e-mails, just tell me who :-)
11:22 dj-death: jekstrand: one question, who's going to use the GET_FENCE?
11:23 jekstrand: dj-death: We need GET_FENCE to implement the semaphore in AcquireNextImage
11:24 jekstrand: There, we would do GET_FENCE and then stuff it in the timeline
11:24 jekstrand: I think we can do that...
11:26 dj-death: jekstrand: isn't that potentially racy?
11:27 jekstrand: why?
11:28 dj-death: jekstrand: if you send an image for presentation and your app grabs the fence right before another frame is rendered by the compositor, you might render to a frame currently presented
11:28 dj-death: jekstrand: because it seems like there 2 processes are calling SET_FENCE
11:29 dj-death: jekstrand: or I'm missing something, app does SET_FENCE to set the wait for the compositor, compositor does SET_FENCE for the acquire
11:29 jekstrand: I think it's ok but also, it's lunch time. Feel free to keep typing. I'll reply in an hour or so.
11:29 dj-death: jekstrand: enjoy
11:31 dj-death: jekstrand: actually I'm missing that there is a layer of protocol on top of the kernel uAPI
11:32 dj-death: jekstrand: so app/compositor are only supposed to do the GET_FENCE after they received a message that happens after a SET_FENCE from the other side
11:36 dj-death: jekstrand: I guess the additional thing we might need is not a reset but a manual signal, unless signaling from userspace requires forging its own signaled fence :)
11:38 danvet: ascent12, ah, that's at least not totally useless
11:38 danvet: re fallback to non-modifier
11:38 danvet: just unplug 2nd screen when gaming :-)
11:38 ascent12: Worst case is the driver just picks the same one, though.
11:39 ascent12: We really need to do pruning.
11:47 dj-death: jekstrand: making GET/SET_FENCE deal with a syncobj would take care of that userspace signaling issue
12:35 jekstrand: dj-death: The SET_FENCE is a signal operation
12:37 dj-death: jekstrand: but the fence might not be signaled yet
12:37 dj-death: jekstrand: I was thinking about the case where you application's buffer ends up on the display directly
12:39 jekstrand: As long as the SET_FENCE in the client happens before the GET_FENCE in the compositor, we should be ok and I think the protocol guarantees that.
12:39 jekstrand: It does mean that we have to delay the wl_surface::commit or XCopyArea until we have a real fence and have set it via SET_FENCE
12:41 dj-death: yeah
13:24 tjaalton: does mesa symbols check tests require an unreleased libdrm?
13:25 tjaalton: or something
13:25 tjaalton: ahh, python fail
14:28 schurig: hi, if I want to get etnaviv for an i.MX6 board running with current Debian Stable (libdrm 2.4.97-1) ... is it recommended I make my own .deb packages from freedeskop's mesa and/or drm git trees?
14:28 schurig: I'll already will be using kernel 5.5.x, not Debian's kernel
15:38 hakzsam: is this assumed that nir_op_flt without the exact bit can't have NaNs?
16:07 seanpaul: bbrezillon: http://paste.debian.net/1129139/ <- any ideas?
16:08 seanpaul: occurs when plugging in MST bridge with 2 downstream sinks
16:32 bbrezillon: seanpaul: can you pass this backtrace to scripts/decode_stacktrace.sh ?
16:34 seanpaul: bbrezillon: i've moved on from that build, i'll see if i can get it back and get that for you
16:48 bbrezillon: seanpaul: IIUC, you have no drm_bridge attached to the mst encoder
16:49 seanpaul: bbrezillon: nope, no bridge on this device
16:49 seanpaul: hmm, thought i updated IRC but scrollback says otherwise, this also happened without MST
16:49 bbrezillon: look like encoder->bridge_chain is corrupted somehow
16:49 bbrezillon: *looks
16:51 bbrezillon: it's supposed to be initialized to an empty list in drm_encoder_init(), and this list should stay empty unless you have a drm_bridge_attach() somewhere (doesn't seem to be the case in the i915 driver)
16:57 seanpaul: bbrezillon: http://paste.debian.net/1129147/
17:01 bbrezillon: seanpaul: thx
17:01 bbrezillon: seanpaul: drivers/gpu/drm/drm_bridge.c:941?
17:02 bbrezillon: is it drm-misc-next?
17:02 seanpaul: bbrezillon: no, i'm in drm-intel
17:02 seanpaul: i'm trying to get it to repro on a tag so we can sync up on source
17:03 bbrezillon: seanpaul: drm-intel-next?
17:03 seanpaul: having other unrelated (i think) ghosts in my device which is making this slow going
17:09 bbrezillon: seanpaul: hm, looks like the intel-next branch is based on a broken version of drm-misc-next
17:09 bbrezillon: one that included broken drm/bridge patches
17:10 bbrezillon: which have been reverted
17:10 seanpaul: bbrezillon: ahh, well that would explain a lot :-)
17:10 seanpaul: vivijim, dolphin: ^^
17:12 seanpaul: i'd move over to drm-tip, but that doesn't boot for me either, i guess i'll try cobbling together a franken-tree of merges until i get something that works
17:17 bbrezillon: seanpaul: have you tried merging drm-misc-next in drm-intel-next?
17:18 seanpaul: bbrezillon: i think that'll be my first step, depending on how recent -misc-next has had a backmerge
17:18 seanpaul: getting no love from 5.6, and early rc's of 5.5 also don't boot
17:18 seanpaul: so i need to find that sweet spot :-)
17:19 seanpaul: might be able to do -misc-next + v5.5 + -intel-next, but have to recover my brick^Wdevice first
17:22 Lyude: any way we could get a backmerge on drm-misc-next from drm-misc-fixes?
17:24 seanpaul: Lyude: usually doesn't work that way, -fixes usually get backmerged to -next from linus (via drm-next). that said, does -misc-fixes have something that linus doesn't have? -misc-fixes should be inactive right now since we're in a merge window
17:25 Lyude: seanpaul: I think it does but I pushed it a week or two ago, when dd the merge window open?
17:25 seanpaul: Lyude: 1/26
17:26 seanpaul: if the patch didn't make it, probably want to get a -misc maintainer to cherry-pick that patch into -misc-next-fixes (possibly with cc:stable if warranted)
17:27 Lyude: seanpaul: ok, I pushed some stuff to the wrong branch it ppears :S, although it looks like the patches I was specifically looking at ("drm/dp_mst: Have DP_Tx send one msg at a time" 5a64967a2f3bbc01cc708ee43c7b0893089c61c4 got pushed before the 26th
17:28 seanpaul: Lyude: ah, success then, both mst patches by Wayne got in
17:29 karolherbst: does a CI fail like that happen more often? https://gitlab.freedesktop.org/karolherbst/mesa/-/jobs/1542098
17:29 seanpaul: Lyude: but the other patches on top of drm-misc-fixes-2020-01-22-1 need to find a new home
17:29 Lyude: seanpaul: alright, and I should let a maintainer do that and not just cherry-pick them myself?
17:30 seanpaul: Lyude: i'd recommend at least getting an ack from mlankhorst_ or mripard before doing that
17:30 Lyude: gotcha
17:30 seanpaul: they might want to reset -misc-fixes
17:32 danvet:generally recommends a merge
17:32 danvet: otherwise you end up with the patch 2x
17:32 danvet: and git gets confused about these
17:32 danvet: so just ping current -misc-next-fixes maintainer to do that merge
17:33 seanpaul: we should probably get another former -misc maintainer to chime in here, this is much more fun than doing the work...
17:33 MrCooper: karolherbst: don't think I've seen that before
17:33 danvet: mlankhorst_, ^^ seems to be your turn
17:34 MrCooper: karolherbst: those tests normally pass in under a second
17:34 karolherbst: MrCooper: mhhh... I reran the task and now it went through.. maybe some really really ugly case of not init memory
17:34 karolherbst: let's see what libasan has to say, maybe it finds something
17:34 MrCooper: could be
17:35 MrCooper: UBSAN certainly flags a bunch of issues in GLSL code
17:43 Lyude: agd5f: think you could pick up and push https://patchwork.freedesktop.org/series/72501/ btw?
18:24 agd5f: Lyude, yeah, thanks for the reminder
19:51 airlied: danvet: sorry went to bed, was the ttm-prot-fix pull from Thomas Hellstrom
20:13 danvet: airlied, fix in your inbox, pls ack
20:13 danvet: oh maybe I should take the debug crap out :-)
20:14 danvet: airlied, https://paste.debian.net/1129175/ or ack here
20:19 diddledan: I've written up everything I can think of to help someone try to understand my infinite recursion problem at https://gitlab.freedesktop.org/mesa/mesa/issues/2469
20:19 gitbot: Mesa issue 2469 in mesa "Infinite recursion with xserver and Indirect GLX (specific to a single third-party library)" [Opened]
20:23 airlied: danvet: ack
20:23 airlied: make sense
20:25 danvet: vivijim, ^^ you're ok too with v2?
20:36 tjaalton: eric_engestrom: you had some suspicions that some format work you did might have endianness issues? I have test results from s390x etc now, if you're interested
21:06 eric_engestrom: tjaalton: I think you meant to tag anholt?
21:07 vivijim: danvet: yeap... just sent the rv-b
21:07 tjaalton: eric_engestrom: ah, could be :)
21:27 danvet: vivijim, thx
21:33 agd5f: ugh removing the driver load an unload callbacks is awful
21:36 tjaalton: anholt: so I believe !1899 is the root of the format failures on big-endian..
21:37 anholt_: tjaalton: it does seem possible, do you have a bisect to a commit?
21:38 tjaalton: anholt_: nope
22:42 tjaalton: anholt_: bisecting now, but actually 1899 landed in 20.0, not 19.3 so the openscad failure there was caused by something else