00:00 airlied: yay one less headache to hammer my head against
00:00 anholt_: jenatali: huh, doesn't seem to affect cts runtime on tu or radv, for example.
00:01 jenatali: anholt_: weird... Maybe it's something else
00:07 jenatali: I did a run earlier and it took an hour, but with the caches it was halfway done at 20mins.
00:10 Venemo: airlied: no, MS don't support transform feedback. if you want it you should implement it in the shader
00:30 zmike: nobody wants xfb
02:21 graphitemaster: Is there any plans for ACO to be used for GL as well, or is it still Vulkan only?
02:26 airlied: there are plans, but there is a lot of things to fix
03:30 Skillingford: Don't let Micky Mouse diddle your little boy! Mickey was busted by Chris Hansen on To Catch a Predator trying to buttscrew a 13 y/o boy in a sting operation! Read all about it here: https://pastebin.com/edvNf8kn Ron Desantis 2024
04:50 DeSantis: Don't let Micky Mouse diddle your little boy! Mickey was busted by Chris Hansen on To Catch a Predator trying to buttscrew a 13 y/o boy in a sting operation! Read all about it here: https://pastebin.com/edvNf8kn Ron Desantis 2024
06:16 tnt: So wrt to the message "Haswell Vulkan support is incomplete" : Is there a list/detail somewhere about what is not there ? What is expected to be broken and what should be working ?
06:39 javierm: emersion: it seems that Zack agress with you that having a new plane type for virtual cursor may not be the correct approach, but that's what danvet suggested
06:40 javierm: so there's some agreegment to be made for that series still (plus the testing that you mentioned)
06:40 danvet: javierm, iirc (I didn't look) I only meant a new type internally in the kernel
06:41 danvet: if userspace sets the "I do understand virtual cursors" flag you'll still get the thing as a normal cursor since it can be otherwise identified
06:41 danvet: you = userspace, get the thing = getplanes ioctl
06:42 danvet: but userspace which doesn't set this flag will not enumerate virtual cursor planes in the getplanes ioctl
06:45 javierm: danvet: ah, so is not really a new plane type but either a normal cursor plane (DRM_PLANE_TYPE_CURSOR) or no cursor plane at all (only a DRM_PLANE_TYPE_PRIMARY)
06:45 danvet: yea
06:46 danvet: I mean you can bikeshed it how you want really, the important part is the filtering
06:46 danvet: javierm, also we don't actually disable the cursor itself, i.e. the legacy cursor plane api would work either way
06:46 danvet: otherwise regressions
06:47 danvet: only targeting getplanes should allow us to precisely snipe this for atomic userspace only
06:47 javierm: danvet: I thought the agreegment was that it wouldn't really be a regression, since iether compositors are not using atomic KMS (mutter, kwin) or falling back to SW cursors (wlroots, weston)
06:48 danvet: javierm, for atomic yes
06:48 danvet: but legacy kms we shouldn't break, that's the part I mean
06:50 javierm: danvet: ah, right. I meant just for atomic
06:57 javierm: danvet: Zack's v2 already does what you suggest I believe: https://paste.centos.org/view/raw/c200dd92
06:58 javierm: I think then your only complain is that DRIVER_VIRTUAL capability is too broad / generic and instead you want something like DRIVER_CURSOR_HOTSPOT ?
06:59 javierm: or DRIVER_CURSOR_COMMANDEERING
07:02 javierm: danvet: in this patch I mean https://lore.kernel.org/all/20220712033246.1148476-2-zack@kde.org/
07:12 bbrezillon: mbrost: thanks
07:16 danvet: javierm, no opinion on the driver flag bikeshed :-)
07:16 danvet: javierm, also emersion acked that old series? where's the disagreement?
07:21 javierm: danvet: https://lore.kernel.org/all/YvPfedG%2FuLQNFG7e@phenom.ffwll.local/ is what you commented
07:21 danvet: yeah just read it
07:21 danvet: I still think it's a bit unecessarily broad name and driver feature flag instead of something on the cursor (flag or whatever) feels cleaner
07:21 danvet: but also meh, clearly a bikeshed :-)
07:22 danvet: whatever color choice the uapi itself is the right one
07:24 javierm: danvet: Ok, I'll answer to latest Zack email then and also mention this. I agree that DRIVER_VIRTUAL isn't self explanatory (since as you correctly pointed out vkms is also virtual)
07:25 jadahl: javierm: in the most recent series, are the hotspot property exposed on all planes?
07:26 jadahl: answering myself: looks like only for cursor planes
07:26 javierm: jadahl: yeah, only cursor planes AFAIU
07:29 jadahl: I say: go with the current version; same plane type, added client cap, and a property
07:30 javierm: jadahl: agreed. It seems is just a bikeshed of the proper name for the cap
07:32 jadahl: yea, not to confuse with vkms has a point
07:32 javierm: yeah
07:33 jadahl: can you ping me when you cc:ed? my filters (skip inbox for lkml) was wrong until a while ago making me miss mails
07:33 jadahl: ?
07:33 javierm: jadahl: sure thing
07:35 jadahl: can it be s/virtiual/vm/ instead perhaps to avoid confusing with vkms? or is that too narrow?
07:41 danvet: jadahl, oh proper kerneldoc for the hotspot properties would be needed
07:41 danvet: since it's not just the hotspot, the presence of these also indicates that this is a cursor that's getting commandeered
07:42 danvet: which also would gives us a natural place to set the plane->commandeered_cursor flag instead of DRIVER_VIRTUAL
07:42 danvet: i.e. drivers just call drm_plane_create_hotspot_properties and don't need to set a separate thing
07:42 danvet: which is much better because separate things tend to get separated and go out of sync :-)
07:44 danvet: minimally put a WARN_ON into drm_plane_create_hotspot_properties to assert that DRIVER_VIRTUAL is set
07:46 Hi-Angel: Any ideas how to debug the cause of such error in a WINE game "warn:opengl:glFlush glFlush returned 0xc0000005". I tried `LIBGL_DEBUG=verbose MESA_DEBUG=1` but it prints no additional information before the error happens, so… 🤷‍♂️ `apitrace` doesn't record WINE (I just created a report on that). So far I only found the problem doesn't happen with `LIBGL_ALWAYS_SOFTWARE` set.
07:54 kode54: try running the windows version of apitrace on top of the program?
07:56 javierm: danvet: the driver caps are internal to the kernel anyways, right? That is, we can later change it without affecting the uAPI
07:56 danvet: yeah
07:57 MrCooper: Hi-Angel: is there any issue other than the message? glFlush doesn't return anything, so it's unclear what the message is on about
07:59 kode54: meanwhile
07:59 danvet: javierm, I replied on-list that minimally we need the warn_on
07:59 kode54: I've been testing the Xe kernel driver
07:59 danvet: javierm, btw I think igt and obviously some userspace missing too?
07:59 kode54: I have to roll my own uAPI header for mostly usable experience
07:59 danvet: not just the property uapi docs
08:00 danvet: but emersion usually catches these things
08:00 kode54: I actually use mlankhorst 's preliminary rewrite, no idea what happened to that thread, it seemed to die or something
08:01 kode54: either way I have to use a different uAPI header if I want 32-bit userspace working
08:01 javierm: danvet: yeah, I agree with igt tests. I just don't think that's fair that people were asking Zack to test corner cases like having two different compositors in different seats, etc
08:02 kode54: what
08:02 Hi-Angel: MrCooper: yeah, the game just stops updating the screen. I *think* it's because of the glFlush, because I tested with `WINEDEBUG=warn+all` with and without SW-based driver, and the only difference in the output is exactly that line with glFlush. When it's missing, the game works as expected.
08:02 danvet: javierm, yeah there's some corner cases with this that are a bit screwed
08:03 Hi-Angel: (it's an old game btw, but my friend still plays so… would like to fix that if possible)
08:03 danvet: like when you switch from a vm cursor aware compositor to one that isn't
08:03 danvet: and the former left the cursor behind
08:03 danvet: it's the age-old "how to make sure vt switch works against broken/nasty compositors"
08:03 kode54: "simple"
08:03 kode54: lovingly hand-craft a broken compositor and test it
08:03 danvet: imo upgrade compositors so they understand these cursors and at least clear them when they don't want to use them is the robust way
08:04 javierm: danvet: yeah, I understand that might be a problem but seems to me more theoretical than something that would be done in practice
08:04 danvet: kode54, artisanal compositor crafting ftw
08:04 danvet: javierm, yeah imo not a concern
08:05 kode54: the real problem is when someone blocks your patches from merging on the condition of this asinine edge case testing being done
08:05 danvet: like the current situation is that these compositors get their cursor randomly yanked
08:05 danvet: kode54, airlied and me try really hard to enforce pragmatic approach when this happens
08:05 kode54: meanwhile, am I being a butt for suggesting that the upstream merge of Xe at least get 32-bit userspace working?
08:05 danvet: kode54, oh they screwed that up?
08:06 kode54: yeah, the header aligns differently depending on the word size
08:06 danvet: exhibit A Steam games pretty much means it has to
08:06 danvet: plus we really don't want to merge ioctl that are butchered like this
08:06 danvet: kode54, if they're broken maybe xe team should write a header file check that guarantees things are right
08:06 kode54: mlankhorst submitted a patch a month ago that modifies the uAPI to guarantee safe alignment, at the expense of breaking compat with existing preliminary user space drivers
08:06 danvet: ogabbay, rodrigovivi ^^
08:07 danvet: kode54, oh those don't matter
08:07 danvet: not for upstream at least
08:07 kode54: he fed it through pahole
08:08 kode54: I found success in my own case of 32/64 mixing when I hand aligned it, but that's not trustworthy
08:08 kode54: I basically went with the rule of every 64 bit field needing at least an even number of 2x 32 bit fields, or 4x 16 bit fields, or combinations thereof
08:08 kode54: and the same for 32 bit fields vs 16 bit
08:08 kode54: but pahole automates this, doesn't it?
08:09 kode54: this, plus one more issue, are stopping me from using unmodified drm-xe-next
08:09 kode54: I also submitted a single-line change
08:10 kode54: it defines the .compat_ioctl member of the fs struct to point to drm_compat_ioctl
08:10 kode54: the specific uAPI is already supposed to be uarch safe
08:10 kode54: but the generic DRM uAPI is not, and needs a couple of fixups, which that basic fallback function handles
08:11 kode54: okay, I just built 6.3.r1171598.9f096ce76f32-1, then I'm going to update my Mesa Git, and reboot and hope this works still
08:12 javierm: kode54: yeah, danvet wrote an excellent document about all that https://www.kernel.org/doc/Documentation/process/botching-up-ioctls.rst
08:13 danvet: kode54, for the missing drm_compat_ioctl I guess that's another case of a few missing igts we really should have as driver agnostic things
08:13 danvet: ogabbay, rodrigovivi ^^
08:14 kode54: funny thing
08:14 kode54: someone either in the list or the tracker said they tested 32 bit
08:14 kode54: with a 32-bit kernel
08:14 danvet: javierm, do you need me to reply with the "what's missing, what's not" on the thread?
08:14 danvet: or all ok since it's really not anything different from the usual
08:14 danvet: kode54, lol
08:14 danvet: as if 32bit kernels are a thing
08:15 kode54: I am amazed anyone is running 32-bit kernels against tigerlake or newer, or a DGPU with 8GB or 16GB of VRAM
08:15 danvet: I mean, for Xe
08:15 danvet: yeah :-)
08:15 kode54: I already accidentally booted it with ReBAR disabled last week or so
08:15 kode54: (after some cmos resets)
08:15 javierm: danvet: I don't think that's needed for now. Thanks for your help
08:15 kode54: the result was that random things didn't work
08:16 kode54: like cursor planes
08:16 kode54: ie. I had no cursor
08:16 danvet: oops
08:16 javierm: danvet: again, all I wanted was to have proper damaged area reporting for virtio-gpu and I ended in yet another rabbit hole :)
08:17 danvet: javierm, it do be like that sometimes
08:17 danvet: javierm, I think it's a sign for the maturity of drm/kms, the leftover unfixed corners are rather tricky
08:18 kode54: amusing thing was
08:18 kode54: someone on the tracker saw my request and pointed me at the proposal document
08:18 kode54: and said something about how this driver isn't being enabled without force_probe anyway, so why fix this now
08:18 kode54: btw
08:19 kode54: Arch default kernel config sets i915.force_probe="*" for quite a while now
08:19 kode54: rather CONFIG_DRM_I915_FORCE_PROBE="*" in the config file
08:20 kode54: guess they wanted DG2 working even before it was ready
08:22 kode54: dammit, another rebuild of all my kernel images for a systemd update
08:22 kode54: I need to research how to make a commandline for only one specific kernel flavor
08:22 kode54: I currently set modprobe.blacklist=i915 on the drm-xe-next one
08:23 ogabbay: danvet: thx for the pointer, will take a look
08:23 kode54: sorry for the hassle
08:24 danvet: dolphin, tursulin, jani, rodrigovivi ^^ apparently arch linux sets force probe unconditionally for anything, time to rename it once more?
08:24 danvet: *sigh*
08:24 dolphin: yeah, I was kind of against the ability to pass force_probe=* to begin with, as this could be seen coming
08:25 dolphin: if they explicitly added some specific card to be always used, that would be a fine distro decision, but makes future more difficult if there is a wildcard...
08:25 kode54: maybe they should have a guide instead, telling users to lspci and find their devids and set their commandline on install
08:25 kode54: if the driver isn't loading
08:26 kode54: they could at least keep this specific to whatever devices are currently force_probe only
08:26 kode54: the guide that is
08:26 HdkR: kode54: 32-bit kernel won't uncover the compat ioctl problems sadly
08:26 kode54: I mean, how many i915 devices are currently force probe?
08:26 dolphin: well, they could have added DG2 ids there, but chose the lazy option
08:26 kode54: HdkR: I know
08:27 kode54: dolphin: is DG2 still force_probe only?
08:27 tursulin: i915.force-probe-$machineid :)
08:27 kode54: hah
08:27 tursulin: everything is easily defeatable by distros if they are set to it though..
08:28 dolphin: yeah, I think jani was of the option that we should let distros shoot themselves in the feet and then walk home with missing toes
08:28 tursulin: I think I agree. Doesn't seem to be much sense engaging in an arms race.
08:29 kode54: I currently force_probe xe in my kernel config, because I am lazy, and somehow stupidly think I'll some day switch to a different Xe card
08:29 kode54: like that will happen any time soon
08:29 kode54: I really should just shove the 56a0 in there
08:29 kode54: er
08:30 kode54: yeah, 56a0
08:30 tursulin: reading the scrollback, 32-bit compact should really be something solvable by just fixing the uapi any time before upstreaming and official first gpu supported
08:30 kode54: makes sense
08:30 tursulin: starting with compat wrappers would be a bit sad
08:31 tursulin: or lazy at least, whatever
08:31 kode54: the only compat wrappers are the generic DRM uAPI
08:31 MrCooper: Hi-Angel: likely a Wine internal issue
08:31 kode54: the current uAPI is supposed to be agnostic, but it aligns differently because nobody went over it with pahole first
08:32 Hi-Angel: MrCooper: Idk, the software-based Mesa driver works. Also, I just tested, and I found out that `zink` works as well
08:32 kode54: I'll read your ioctl doc
08:33 MrCooper: Hi-Angel: at any rate, Wine folks should be more helpful for figuring out what that message actually means
08:33 kode54: it's an access denied error, though
08:34 Hi-Angel: yep
08:34 kode54: but who knows why
08:34 Hi-Angel: Yeah…
08:34 kode54: maybe try hitting up #winehackers on libera.chat
08:34 kode54: maybe someone there could find why glFlush would return that error
08:35 kode54: I know #winehq is their support chat
08:35 kode54: but maybe this more calls for hacking around to figure out why something isn't working
08:35 kode54: *shrug*
08:35 emersion: danvet, javierm: the reason i don't like a separate plane type is that it allows mixing regular cursor planes and nested cursor planes
08:36 emersion: it's easier to handle if user-space has a global indication that the driver is nested, and thus all cursor planes are nested
08:36 danvet: emersion, hm but in reality, can that happen?
08:37 danvet: I'd say if you have such hw, these other planes should be overlay planes
08:37 emersion: if it can't happen, why design an uAPI that allows it?
08:37 danvet: "hw"
08:37 danvet: emersion, I don't change the uapi, this is purely an internal thing
08:37 emersion: oh
08:37 danvet: having the flag in drm_driver that controls how your cursor works just asks for divergence and resulting trouble
08:37 emersion: if it's internal only, then nvm
08:37 danvet: also, the uapi does already allow this
08:38 emersion: wdym?
08:38 danvet: because the global flag userspace sets is just saying "I can cope with virtual planes"
08:38 danvet: *virtual cursor planes where the cursor moves on its own
08:38 emersion: but the existence of the cap means that the driver is nested?
08:38 danvet: the actual indication whether a cursor is of this type is the presence/absence of the hotspot properties
08:38 danvet: I don't think so
08:38 emersion: okay, i don't remember
08:38 danvet: it's like setting the universal planes/atomic kms flag
08:39 danvet: well there's no uapi doc in this patch series that actually explains it all, so that doesn't help
08:39 emersion: some drivers don't support atomic/universal planes
08:39 emersion: same here
08:39 danvet: so there's no clear spec for how these special cursors actually work
08:40 emersion: alright, i'll have another look when the new version comes in then :)
08:40 emersion: will be easier to discuss
08:40 emersion: in any case it's in the right direction
08:40 danvet: emersion, yeah atomic flag fails if the driver doesn't support it
08:40 danvet: unverisal planes always works
08:40 emersion: ah right
08:40 emersion: either (cap fails, or user-space discovers the hotspot props) sounds fine to me
08:40 MrCooper: kode54: glFlush can't return anything, the error is from a Wine internal function
08:41 emersion: former could be more useful as pq said
08:41 danvet: I prefer flags to just enable features and not work for discovery
08:41 emersion: … but the swapchain depth thing is a more general i suppose
08:41 danvet: again because the flag is separate from the code that implements something
08:41 kode54: MrCooper: ah, so maybe it's SetLastError somewhere
08:41 emersion: for instance remote drivers could benefit from increased swapchain length
08:41 emersion: like gud
08:41 danvet: atomic is the only exception really, because we have drivers which are internally using atomic
08:41 danvet: but don't uphold the full tear-free uapi promise
08:41 kode54: meanwhile
08:42 javierm: danvet, emersion: yeah, similar to how for example writeback connectors are handled
08:42 danvet: so don't set the uapi flag
08:42 javierm: are only exposed if the flag is set
08:42 danvet: javierm, yup exactly
08:42 kode54: the Mesa userspace has some minor glitching with Xe, but that can be fixed later, assuming it's not some kernel synchronization that's failing
08:42 kode54: I posted a separate issue on Mesa
08:42 emersion: fwiw, my comments are about the uAPI unless otherwise specified
08:42 emersion: i don't care too much how the internals are implemented
08:42 danvet: yeah figured
08:43 danvet: docs for the uapi props should help with clarifying all this
08:43 emersion: but yeah, as you said we need to make sure legacy is not broken
08:43 emersion: yea
08:43 javierm: emersion: agreed, legacy and atomic with SW cursors
08:45 jadahl: how would you auto-disable the cursor if you switched to a drm client that didn't set the cap/
08:45 jadahl: ?
08:45 jadahl: *cursor plane
08:45 jadahl: or is that the edge case to not care about too?
08:46 javierm: jadahl: my understanding is that the compositor that is being switched from should disable it ?
08:46 javierm: but yes, that's the edge case that we were talking about
08:47 emersion: javierm: no, compositors being switched away leave the state as-is
08:47 jadahl: yea
08:47 emersion: to allow the new DRM master to perform a seamless transition
08:48 emersion: there is no solution to this issue, and it's not specific to virtual cursors
08:48 jadahl: thus shouldn't block the virtual cursor series...
08:48 emersion: if a plane has alpha=0, then a new DRM master who doesn't know about the alpha prop will just display incorrectly
08:49 danvet: jadahl, if you do nuke the compositor the rmfb ioctl should clean up any planes at least
08:49 jadahl: thats a good point
08:49 jadahl: won't help with just switching vt back and forth
08:49 jadahl: but meh
08:49 danvet: but yeah vt switching among compositors with disjoint feature sets is just generally ill defined, nothing new
08:50 jadahl: it's more important that going login screen -> session compositor where that does things differently behaves sanely
08:50 jadahl: and sounds like it should
08:50 jadahl: in this case at least
08:50 danvet: a fix would be if compositors composite down to a single primary plane before switching as the common denominator that everyone can cope with
08:51 emersion: that doesn't help with crashes
08:51 javierm: emersion, jadahl: ah, misunderstood then. Thanks for the clarification
09:05 jani: danvet: dolphin: yeah, I'm inclined to let distros shoot themselves in the feet
09:09 airlied: as long as we don't ever have uapi features appears under that flag
09:09 danvet: jani, it's more that we might get regression reports and they still count
09:09 danvet: but we can rename when that happens I guess
09:09 danvet: not the first time :-/
09:10 danvet: regression as in "the driver now binds and now I get a black screen, fix it"
09:11 jani: danvet: "Force probe the i915 for Intel graphics devices that are recognized but not properly supported by this kernel version."
09:12 jani: danvet: if we're saying it's not supported...
09:14 danvet: a regression is a regression is a regression
09:14 danvet: I mean we can do some arm twisting, but that's about it
09:14 danvet: (probably a lot of arm twisting for this kind of silliness)
09:15 jani: danvet: https://paste.debian.net/1279149/
09:16 danvet: hm don't we do that already because it's an unsafe option?
09:16 jani: danvet: that's the thing, the module parameter taints, but the kconfig does not
09:16 danvet: oh
09:16 danvet: good point, I guess land it asap :-)
09:17 danvet: a-b: me
09:17 jani: ok
09:17 danvet: maybe add a fixes: for the commit that added the kconfig
09:20 kode54: this was the patch series I am currently using for uAPI
09:20 kode54: https://patchwork.freedesktop.org/patch/529156/?series=115709&rev=1
09:21 kode54: at the very least, it was requested to split the uAPI changes and the padding/field MBZ tests into separate commits
09:21 kode54: also people replying to the patch quoted the whole damn thing in their replies
09:22 kode54: I also tested intel-compute-runtime from a recent release version with Xe support, and stuffed in this xe_drm.h, and it just hangs
09:22 kode54: but it also hung with unmodified kernel and intel's own binaries
09:23 kode54: I reported that to Intel, not sure where that's going right now
09:23 kode54: also, that changed uAPI appears to need some reversions or changes instead
09:24 kode54: because of breaking compat with tests that were designed for i915
09:24 kode54: because it changes sizes of various members instead of strictly adding padding
09:24 kode54: it also reorders a few places
09:25 kode54: so it's technically not even compatible with 64 bit userspace without also replacing the uAPI header there
09:25 kode54: bed time
09:50 jani: danvet: patch on the list
10:35 danvet: acked
11:25 DavidHeidelberg[m]: zmike: piglit.trace.gl-zink-anv-tgl.freedoom/freedoom-phase2-gl-high_trace maybe regressed also from 1080ff39717b92b99afcf51283bec3994deae376..ef01a9cf3b465889fe8084732264dad0580270c3 as the radv stuff? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22820
11:49 eric_engestrom: PSA: mesa 23.1.0 final will be released in a few hours; ping me immediately if you have a regression that you forgot to add to the release blocker milestone (https://gitlab.freedesktop.org/mesa/mesa/-/milestones/42), otherwise I'll proceed :)
11:49 eric_engestrom:is suspicious of how smooth this rc series has seemed
12:35 zmike: eric_engestrom: I was actually about to open one :/
12:52 kisak: and here I as about to write congrats on getting it out on the first option.
13:20 mlankhorst: Yeah plus I checked everything for 0
13:43 zmike: DavidHeidelberg[m]: seems unlikely it's related to the multisample thing since it was working fine before that
13:57 Hi-Angel: kode54: turns out, Windows version of apitrace doesn't produce any trace files as well 🤷‍♂️
15:12 pac85: I wonder if the fails on freedom could be related with https://gitlab.freedesktop.org/mesa/mesa/-/issues/8910 as I recall seeing glitches as really poor performance. I say that because it could be the same engine (gzdoom)
15:34 mbrost: bbrezillon: thanks for starting a discussion on the resubmit... a lot to catch up on
15:41 bbrezillon: mbrost: yeah, things are progressively getting clearer, but it's not crystal clear yet
15:44 mbrost: I think so, this comment makes me happy
15:44 mbrost: What we should do in the GPU scheduler instead is the follow:
15:44 mbrost: 1. Don't support re-submission at all!
15:44 mbrost: Instead we can provide help to drivers to query which fences (scheduler or hw) are still not signaled yet.
15:44 mbrost: This can then be used to re-create hw state if (and only if!) the driver knows what it's doing and can actually guarantee that this will work.
15:44 mbrost: E.g. the case for XE where the kernel driver knows the contexts which were not running at the time and can re-create their queues.
15:44 mbrost: 2. We can provide both a wq to use for single threaded application as well as start/stop semantics.
15:44 mbrost: It's just that the start/stop semantics should never touch what was already submitted, but rather just make sure that we don't get any new submissions.
15:44 mbrost: Regards,
15:44 mbrost: Christian.
15:44 mbrost: This is spot on
15:47 mbrost: Basically exactly what we do in Xe, the only resubmission we support are when the entire GPU is toast and the only things we resubmit are things we know that didn't cause the hang (e.g. are entity a job that has started but nit completed we just ban entity)
15:47 mbrost: If entity ever hangs on it own, we ban it
15:48 mbrost: start/stop/resubmit are still required, the WQ gives the option single or multi-threaded
15:49 mbrost: I'll try to reply on the list but in and out today + my linux email client isn't behaving today so it might be an outlook reply
15:50 mbrost: s/(e.g. are entity a job that has started but nit completed we just ban entity/(e.g. any entity which has a job that has started but not completed we just ban entity/
15:52 mbrost: the way we use stop/start/resubmit they really can't be abused, agree with Christian if you did anything more wild than what do in Xe you areasking for serious trouble
15:52 mbrost: and it probably would not work
15:58 mbrost: if your curious in Xe we write a seqno when a job starts and another one when it completes if they are not equal that how we know a job started but didn't complete
15:58 mbrost: which in turn is how we find an possible entities that caused the entire GPU to hang and ban them
16:01 mbrost: gotta run
16:34 zmike: anholt_: is there any sort of size limit on traces we use for ci?
16:35 anholt_: Basically no. Like, if it's huge, it should be worth it.
16:35 anholt_: (see the README)
16:36 zmike: hmmm
16:37 zmike: I was considering a csgo trace, which I've trimmed down to one frame, but it's 1.2gb
17:33 anholt_: zmike: would love to see a csgo in traces-db (doesn't even need to be -private!). I think 1.2gb is worth it for that one. I'd love to have the trim keep 3 drawing frames (or whatever it is that you could loop the drawing frames so you don't get unrepresentative syncing)
17:34 anholt_: we haven't been keeping >1 rendering frame in traces-db, and we don't have "loop last n" in apitrace yet, but we very much need to sort that out.
17:39 zmike: I've got a pretty big trace atm so I could easily cut 3 frames
17:44 graphitemaster: I don't think parallel compile works correctly in mesa. Something in here is not setting completion value so my engine is just stuck polling for completion...
17:45 graphitemaster: The update loop looks something like this https://gist.github.com/graphitemaster/6a65dea19e555955e535448e404035dc
17:46 graphitemaster: Am I doing something wrong?
17:48 graphitemaster: Seems COMPLETION_STATUS_ARB on the linking stage just never gets set to true
17:49 anholt_: that's going to be driver dependent.
17:49 anholt_: so, report it to your driver.
17:55 graphitemaster: It looks like when linking fails in mesa it doesn't set completion status to true
17:55 graphitemaster: completion status and linking status are the same case in the switch statement
17:55 zmike: can you file a ticket
17:56 graphitemaster: Yeah
17:56 zmike: thx
18:01 graphitemaster: Oh I might've been looking at older source code
18:18 graphitemaster: Okay mesa update fixed it, false alarm!
20:13 lumag: jani, please excuse me, yet another gracious ping for the https://patchwork.freedesktop.org/series/114473/ series
20:13 lumag: The list of patches depending on this series starts to pile up on our side.
20:48 jenatali: Vulkan CTS question: If I implement a workaround for a missing feature, and put it behind an environment variable, am I allowed to do a CTS submission with that variable set? Or is that disingenuous because users wouldn't have it set?
20:49 airlied: we've tended towards the latter
20:49 jenatali: Tl;dr I have 37 test failures that are due to overly-strict validation in the DXIL validator. If I disable the validator, the shaders work just fine, but that's a bad idea in general
20:50 jenatali: The other option is to try to get a waiver, or wait until the dependent component gets fixed
20:51 jenatali: That might be a while though :(
20:51 airlied: like if a user tries to use the feature and dxil validation blocks them, what's the point in exposing it?
20:51 jenatali: It's required
20:52 jenatali: Specifically shadow bias/gradient sampling
20:52 airlied: but you aren't really meeting the requirement
20:52 airlied: since a user can't actaully use the feature in real life
20:52 jenatali: Yeah. Fair
20:52 jenatali: Sigh guess I play the waiting game then
20:53 airlied: don't you control the dxil validator as well?
20:53 jenatali: Kind of?
20:54 jenatali: Not my team
20:55 airlied: tear down those silos :-P
20:58 jenatali: Yeah I'm looking at my options
21:00 airlied: escalate to satya
21:00 jenatali: Heh. Our first layer of management in common is a bit below that level :)
21:06 HdkR: Just make the driver live patch the dxil validator to disable the overly-strict validation :P
21:07 HdkR: Didn't need those checks anyway
21:09 jenatali: Brilliant!
21:09 jenatali: I could ship a hacked version of the validator
21:10 HdkR: Anti-cheat over here raising an eyebrow from remapping RX to RWX
21:21 Lyude: Hm, does anyone know the difference between DRM_MODE_FLAG_PVSYNC and DRM_MODE_FLAG_NVSYNC? I'm asking as I'm trying to figure out right now what I'm doing wrong when reading back the hw display state for nouveau, as I'm making a mistake with my math somewhere: https://paste.centos.org/view/d9dd839e and I'm wondering if these flags have something to do with it
21:23 Lyude: (also fwiw: I'm pretty confident I'm at least reading back the values from nvidia's state cache correctly, as they don't change at all later on when I check the atomic state after boot, hence my assumption my math is off when translating this into a DRM modeline)
21:29 Lyude: hm, maybe something's happening in drm_mode_set_crtcinfo() that I'm not accounting for
21:30 airlied: konstantin_, zmike : fair bit of CI side swiping with the descriptors MR, might want to make that the priority
21:31 zmike: we've been iterating on that for a few days but I suggested putting up the MR before it was fully green to start getting some feedback
21:31 airlied: also adding that vulkan flag to NIR sets of alarm bells for appeals to higher gfxstrand
22:10 emersion: Lyude: positive/negative sync, VESA specs define what these mean
22:10 emersion: diagrams in EDID spec iirc
22:31 Lyude: emersion: huh, any idea where I can get that (or if it's some non-free standard I've gotta poke VESA about?). I found VESA's free standards page and surprisingly I can find spec sheets for EEDID. I assume that's a different spec then the one you're referring to though
22:31 emersion: you mean you can or cannot?
22:32 emersion: it's a free standard, can get it from their box.com
22:32 emersion: https://app.box.com/s/vcocw3z73ta09txiskj7cnk6289j356b/folder/11133487793
22:33 Lyude: yeah that's the same page that I found, I'm just wondering if you meant the e-edid spec? I don't see any plain EDID spec files listed there, only the e-edid one
22:33 emersion: there are diagrams e.g. in "3.12 Note Regarding Borders"
22:33 Lyude: haha, found it the second you posted that
22:33 Lyude: thanks :)
22:34 emersion: i think other standards had similar diagrams too
22:35 emersion: hm GTF has one but less detailed
22:38 Lyude: mhh, so it just seems like the positive/negative pulse is just describing whether the physical sync pulse along the link goes high or low on a sync?
22:41 Lyude: hm, this is helping a bit with visualizing this in my head though so maybe I can figure out what's going wrong with my math here
22:42 Lyude: the gears are slowly starting to turn…