oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<graphitemaster>
Is there any plans for ACO to be used for GL as well, or is it still Vulkan only?
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
<airlied>
there are plans, but there is a lot of things to fix
kode54 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
aravind has joined #dri-devel
bmodem has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Skillingford has joined #dri-devel
mbrost_ has joined #dri-devel
<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
pallavim has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
Skillingford has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2023-05-03 03:35:26)]
alanc has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
Stary has quit [Ping timeout: 480 seconds]
DeSantis has joined #dri-devel
smiles_1111 has joined #dri-devel
<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
DeSantis has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2023-05-03 04:51:20)]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
dcz has joined #dri-devel
pochu has joined #dri-devel
tnt has joined #dri-devel
<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 ?
smiles_1111 has quit [Remote host closed the connection]
smiles_1111 has joined #dri-devel
danvet has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
itoral has joined #dri-devel
<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
<javierm>
so there's some agreegment to be made for that series still (plus the testing that you mentioned)
<danvet>
javierm, iirc (I didn't look) I only meant a new type internally in the kernel
<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
<danvet>
you = userspace, get the thing = getplanes ioctl
<danvet>
but userspace which doesn't set this flag will not enumerate virtual cursor planes in the getplanes ioctl
<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)
<danvet>
yea
<danvet>
I mean you can bikeshed it how you want really, the important part is the filtering
<danvet>
javierm, also we don't actually disable the cursor itself, i.e. the legacy cursor plane api would work either way
<danvet>
otherwise regressions
<danvet>
only targeting getplanes should allow us to precisely snipe this for atomic userspace only
<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)
<danvet>
javierm, for atomic yes
<danvet>
but legacy kms we shouldn't break, that's the part I mean
frieder has joined #dri-devel
<javierm>
danvet: ah, right. I meant just for atomic
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<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 ?
<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
<danvet>
but also meh, clearly a bikeshed :-)
<danvet>
whatever color choice the uapi itself is the right one
<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)
Hi-Angel has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<jadahl>
javierm: in the most recent series, are the hotspot property exposed on all planes?
<jadahl>
answering myself: looks like only for cursor planes
<javierm>
jadahl: yeah, only cursor planes AFAIU
<jadahl>
I say: go with the current version; same plane type, added client cap, and a property
<javierm>
jadahl: agreed. It seems is just a bikeshed of the proper name for the cap
<jadahl>
yea, not to confuse with vkms has a point
<javierm>
yeah
<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
<jadahl>
?
<javierm>
jadahl: sure thing
<jadahl>
can it be s/virtiual/vm/ instead perhaps to avoid confusing with vkms? or is that too narrow?
<danvet>
jadahl, oh proper kerneldoc for the hotspot properties would be needed
<danvet>
since it's not just the hotspot, the presence of these also indicates that this is a cursor that's getting commandeered
<danvet>
which also would gives us a natural place to set the plane->commandeered_cursor flag instead of DRIVER_VIRTUAL
<danvet>
i.e. drivers just call drm_plane_create_hotspot_properties and don't need to set a separate thing
<danvet>
which is much better because separate things tend to get separated and go out of sync :-)
<danvet>
minimally put a WARN_ON into drm_plane_create_hotspot_properties to assert that DRIVER_VIRTUAL is set
fab has quit [Ping timeout: 480 seconds]
<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.
pcercuei has joined #dri-devel
<kode54>
try running the windows version of apitrace on top of the program?
pinkie[m] has joined #dri-devel
pinkie[m] is now known as val[m]
lynxeye has joined #dri-devel
rasterman has joined #dri-devel
<javierm>
danvet: the driver caps are internal to the kernel anyways, right? That is, we can later change it without affecting the uAPI
<danvet>
yeah
<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
<kode54>
meanwhile
<danvet>
javierm, I replied on-list that minimally we need the warn_on
<kode54>
I've been testing the Xe kernel driver
<danvet>
javierm, btw I think igt and obviously some userspace missing too?
JohnnyonFlame has joined #dri-devel
<kode54>
I have to roll my own uAPI header for mostly usable experience
<danvet>
not just the property uapi docs
<danvet>
but emersion usually catches these things
<kode54>
I actually use mlankhorst 's preliminary rewrite, no idea what happened to that thread, it seemed to die or something
val[m] has left #dri-devel [#dri-devel]
<kode54>
either way I have to use a different uAPI header if I want 32-bit userspace working
vliaskov_ has joined #dri-devel
<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
<kode54>
what
<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.
vliaskov has quit [Ping timeout: 480 seconds]
<danvet>
javierm, yeah there's some corner cases with this that are a bit screwed
<Hi-Angel>
(it's an old game btw, but my friend still plays so… would like to fix that if possible)
<danvet>
like when you switch from a vm cursor aware compositor to one that isn't
<danvet>
and the former left the cursor behind
<danvet>
it's the age-old "how to make sure vt switch works against broken/nasty compositors"
<kode54>
"simple"
<kode54>
lovingly hand-craft a broken compositor and test it
<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
<javierm>
danvet: yeah, I understand that might be a problem but seems to me more theoretical than something that would be done in practice
<danvet>
kode54, artisanal compositor crafting ftw
<danvet>
javierm, yeah imo not a concern
<kode54>
the real problem is when someone blocks your patches from merging on the condition of this asinine edge case testing being done
<danvet>
like the current situation is that these compositors get their cursor randomly yanked
<danvet>
kode54, airlied and me try really hard to enforce pragmatic approach when this happens
<kode54>
meanwhile, am I being a butt for suggesting that the upstream merge of Xe at least get 32-bit userspace working?
<danvet>
kode54, oh they screwed that up?
<kode54>
yeah, the header aligns differently depending on the word size
<danvet>
exhibit A Steam games pretty much means it has to
<danvet>
plus we really don't want to merge ioctl that are butchered like this
<danvet>
kode54, if they're broken maybe xe team should write a header file check that guarantees things are right
<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
<danvet>
ogabbay, rodrigovivi ^^
<danvet>
kode54, oh those don't matter
<danvet>
not for upstream at least
<kode54>
he fed it through pahole
<kode54>
I found success in my own case of 32/64 mixing when I hand aligned it, but that's not trustworthy
<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
<kode54>
and the same for 32 bit fields vs 16 bit
<kode54>
but pahole automates this, doesn't it?
<kode54>
this, plus one more issue, are stopping me from using unmodified drm-xe-next
<kode54>
I also submitted a single-line change
<kode54>
it defines the .compat_ioctl member of the fs struct to point to drm_compat_ioctl
<kode54>
the specific uAPI is already supposed to be uarch safe
<kode54>
but the generic DRM uAPI is not, and needs a couple of fixups, which that basic fallback function handles
swalker__ has joined #dri-devel
<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
<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
<danvet>
ogabbay, rodrigovivi ^^
<kode54>
funny thing
<kode54>
someone either in the list or the tracker said they tested 32 bit
<kode54>
with a 32-bit kernel
<danvet>
javierm, do you need me to reply with the "what's missing, what's not" on the thread?
<danvet>
or all ok since it's really not anything different from the usual
<danvet>
kode54, lol
<danvet>
as if 32bit kernels are a thing
<kode54>
I am amazed anyone is running 32-bit kernels against tigerlake or newer, or a DGPU with 8GB or 16GB of VRAM
<danvet>
I mean, for Xe
<danvet>
yeah :-)
<kode54>
I already accidentally booted it with ReBAR disabled last week or so
<kode54>
(after some cmos resets)
<javierm>
danvet: I don't think that's needed for now. Thanks for your help
Zopolis4_ has quit [Quit: Connection closed for inactivity]
<kode54>
the result was that random things didn't work
<kode54>
like cursor planes
<kode54>
ie. I had no cursor
<danvet>
oops
Haaninjo has joined #dri-devel
<javierm>
danvet: again, all I wanted was to have proper damaged area reporting for virtio-gpu and I ended in yet another rabbit hole :)
<danvet>
javierm, it do be like that sometimes
<danvet>
javierm, I think it's a sign for the maturity of drm/kms, the leftover unfixed corners are rather tricky
<kode54>
amusing thing was
<kode54>
someone on the tracker saw my request and pointed me at the proposal document
<kode54>
and said something about how this driver isn't being enabled without force_probe anyway, so why fix this now
<kode54>
btw
swalker__ has quit [Ping timeout: 480 seconds]
<kode54>
Arch default kernel config sets i915.force_probe="*" for quite a while now
<kode54>
rather CONFIG_DRM_I915_FORCE_PROBE="*" in the config file
<kode54>
guess they wanted DG2 working even before it was ready
thellstrom has joined #dri-devel
<kode54>
dammit, another rebuild of all my kernel images for a systemd update
<kode54>
I need to research how to make a commandline for only one specific kernel flavor
<kode54>
I currently set modprobe.blacklist=i915 on the drm-xe-next one
<ogabbay>
danvet: thx for the pointer, will take a look
<kode54>
sorry for the hassle
<danvet>
dolphin, tursulin, jani, rodrigovivi ^^ apparently arch linux sets force probe unconditionally for anything, time to rename it once more?
<danvet>
*sigh*
<dolphin>
yeah, I was kind of against the ability to pass force_probe=* to begin with, as this could be seen coming
<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...
<kode54>
maybe they should have a guide instead, telling users to lspci and find their devids and set their commandline on install
<kode54>
if the driver isn't loading
<kode54>
they could at least keep this specific to whatever devices are currently force_probe only
<kode54>
I mean, how many i915 devices are currently force probe?
<dolphin>
well, they could have added DG2 ids there, but chose the lazy option
<kode54>
HdkR: I know
<kode54>
dolphin: is DG2 still force_probe only?
<tursulin>
i915.force-probe-$machineid :)
<kode54>
hah
<tursulin>
everything is easily defeatable by distros if they are set to it though..
<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
<tursulin>
I think I agree. Doesn't seem to be much sense engaging in an arms race.
<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
<kode54>
like that will happen any time soon
<kode54>
I really should just shove the 56a0 in there
<kode54>
er
<kode54>
yeah, 56a0
<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
<kode54>
makes sense
<tursulin>
starting with compat wrappers would be a bit sad
<tursulin>
or lazy at least, whatever
<kode54>
the only compat wrappers are the generic DRM uAPI
<MrCooper>
Hi-Angel: likely a Wine internal issue
<kode54>
the current uAPI is supposed to be agnostic, but it aligns differently because nobody went over it with pahole first
<Hi-Angel>
MrCooper: Idk, the software-based Mesa driver works. Also, I just tested, and I found out that `zink` works as well
<kode54>
I'll read your ioctl doc
<MrCooper>
Hi-Angel: at any rate, Wine folks should be more helpful for figuring out what that message actually means
<kode54>
it's an access denied error, though
<Hi-Angel>
yep
<kode54>
but who knows why
<Hi-Angel>
Yeah…
<kode54>
maybe try hitting up #winehackers on libera.chat
<kode54>
maybe someone there could find why glFlush would return that error
<kode54>
I know #winehq is their support chat
<kode54>
but maybe this more calls for hacking around to figure out why something isn't working
<kode54>
*shrug*
<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
<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
<danvet>
emersion, hm but in reality, can that happen?
<danvet>
I'd say if you have such hw, these other planes should be overlay planes
<emersion>
if it can't happen, why design an uAPI that allows it?
<danvet>
"hw"
<danvet>
emersion, I don't change the uapi, this is purely an internal thing
<emersion>
oh
<danvet>
having the flag in drm_driver that controls how your cursor works just asks for divergence and resulting trouble
<emersion>
if it's internal only, then nvm
<danvet>
also, the uapi does already allow this
<emersion>
wdym?
<danvet>
because the global flag userspace sets is just saying "I can cope with virtual planes"
<danvet>
*virtual cursor planes where the cursor moves on its own
<emersion>
but the existence of the cap means that the driver is nested?
<danvet>
the actual indication whether a cursor is of this type is the presence/absence of the hotspot properties
<danvet>
I don't think so
<emersion>
okay, i don't remember
<danvet>
it's like setting the universal planes/atomic kms flag
<danvet>
well there's no uapi doc in this patch series that actually explains it all, so that doesn't help
<emersion>
some drivers don't support atomic/universal planes
<emersion>
same here
<danvet>
so there's no clear spec for how these special cursors actually work
<emersion>
alright, i'll have another look when the new version comes in then :)
<emersion>
will be easier to discuss
<emersion>
in any case it's in the right direction
<danvet>
emersion, yeah atomic flag fails if the driver doesn't support it
<danvet>
unverisal planes always works
<emersion>
ah right
<emersion>
either (cap fails, or user-space discovers the hotspot props) sounds fine to me
<MrCooper>
kode54: glFlush can't return anything, the error is from a Wine internal function
<emersion>
former could be more useful as pq said
<danvet>
I prefer flags to just enable features and not work for discovery
<emersion>
… but the swapchain depth thing is a more general i suppose
<danvet>
again because the flag is separate from the code that implements something
<kode54>
MrCooper: ah, so maybe it's SetLastError somewhere
<emersion>
for instance remote drivers could benefit from increased swapchain length
<emersion>
like gud
<danvet>
atomic is the only exception really, because we have drivers which are internally using atomic
<danvet>
but don't uphold the full tear-free uapi promise
<kode54>
meanwhile
<javierm>
danvet, emersion: yeah, similar to how for example writeback connectors are handled
<danvet>
so don't set the uapi flag
<javierm>
are only exposed if the flag is set
<danvet>
javierm, yup exactly
<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
<kode54>
I posted a separate issue on Mesa
<emersion>
fwiw, my comments are about the uAPI unless otherwise specified
<emersion>
i don't care too much how the internals are implemented
<danvet>
yeah figured
<danvet>
docs for the uapi props should help with clarifying all this
<emersion>
but yeah, as you said we need to make sure legacy is not broken
<emersion>
yea
<javierm>
emersion: agreed, legacy and atomic with SW cursors
<jadahl>
how would you auto-disable the cursor if you switched to a drm client that didn't set the cap/
<jadahl>
?
<jadahl>
*cursor plane
<jadahl>
or is that the edge case to not care about too?
<javierm>
jadahl: my understanding is that the compositor that is being switched from should disable it ?
<javierm>
but yes, that's the edge case that we were talking about
<emersion>
javierm: no, compositors being switched away leave the state as-is
<jadahl>
yea
<emersion>
to allow the new DRM master to perform a seamless transition
<emersion>
there is no solution to this issue, and it's not specific to virtual cursors
<jadahl>
thus shouldn't block the virtual cursor series...
<emersion>
if a plane has alpha=0, then a new DRM master who doesn't know about the alpha prop will just display incorrectly
<danvet>
jadahl, if you do nuke the compositor the rmfb ioctl should clean up any planes at least
<jadahl>
thats a good point
<jadahl>
won't help with just switching vt back and forth
<jadahl>
but meh
<danvet>
but yeah vt switching among compositors with disjoint feature sets is just generally ill defined, nothing new
<jadahl>
it's more important that going login screen -> session compositor where that does things differently behaves sanely
<jadahl>
and sounds like it should
<jadahl>
in this case at least
devilhorns has joined #dri-devel
<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
<emersion>
that doesn't help with crashes
<javierm>
emersion, jadahl: ah, misunderstood then. Thanks for the clarification
robmur01_ is now known as robmur01
<jani>
danvet: dolphin: yeah, I'm inclined to let distros shoot themselves in the feet
<airlied>
as long as we don't ever have uapi features appears under that flag
<danvet>
jani, it's more that we might get regression reports and they still count
<danvet>
but we can rename when that happens I guess
<danvet>
not the first time :-/
<danvet>
regression as in "the driver now binds and now I get a black screen, fix it"
<jani>
danvet: "Force probe the i915 for Intel graphics devices that are recognized but not properly supported by this kernel version."
<jani>
danvet: if we're saying it's not supported...
<danvet>
a regression is a regression is a regression
<danvet>
I mean we can do some arm twisting, but that's about it
<danvet>
(probably a lot of arm twisting for this kind of silliness)
<kode54>
at the very least, it was requested to split the uAPI changes and the padding/field MBZ tests into separate commits
<kode54>
also people replying to the patch quoted the whole damn thing in their replies
<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
<kode54>
but it also hung with unmodified kernel and intel's own binaries
<kode54>
I reported that to Intel, not sure where that's going right now
<kode54>
also, that changed uAPI appears to need some reversions or changes instead
<kode54>
because of breaking compat with tests that were designed for i915
<kode54>
because it changes sizes of various members instead of strictly adding padding
<kode54>
it also reorders a few places
<kode54>
so it's technically not even compatible with 64 bit userspace without also replacing the uAPI header there
<kode54>
bed time
alanc-away has joined #dri-devel
alanc has quit [Ping timeout: 480 seconds]
avoidr has quit [Remote host closed the connection]
<jani>
danvet: patch on the list
avoidr has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<danvet>
acked
kts has joined #dri-devel
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<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
<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 :)
* eric_engestrom
is suspicious of how smooth this rc series has seemed
Stary has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom1 has quit []
thellstrom has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
vliaskov_ has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
<zmike>
eric_engestrom: I was actually about to open one :/
<kisak>
and here I as about to write congrats on getting it out on the first option.
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #dri-devel
vliaskov has joined #dri-devel
<mlankhorst>
Yeah plus I checked everything for 0
i509vcb has quit [Quit: Connection closed for inactivity]
mvchtz has quit [Quit: WeeChat 3.5]
mvchtz has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
fxkamd has joined #dri-devel
jewins has joined #dri-devel
<zmike>
DavidHeidelberg[m]: seems unlikely it's related to the multisample thing since it was working fine before that
<Hi-Angel>
kode54: turns out, Windows version of apitrace doesn't produce any trace files as well 🤷♂️
<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)
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
devilhorns has quit [Quit: Leaving]
aravind has joined #dri-devel
alanc-away has quit [Remote host closed the connection]
alanc-away has joined #dri-devel
kzd has joined #dri-devel
<mbrost>
bbrezillon: thanks for starting a discussion on the resubmit... a lot to catch up on
kts has quit [Quit: Konversation terminated!]
<bbrezillon>
mbrost: yeah, things are progressively getting clearer, but it's not crystal clear yet
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<mbrost>
I think so, this comment makes me happy
<mbrost>
What we should do in the GPU scheduler instead is the follow:
<mbrost>
1. Don't support re-submission at all!
<mbrost>
Instead we can provide help to drivers to query which fences (scheduler or hw) are still not signaled yet.
<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.
<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.
<mbrost>
2. We can provide both a wq to use for single threaded application as well as start/stop semantics.
<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.
<mbrost>
Regards,
<mbrost>
Christian.
<mbrost>
This is spot on
<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)
<mbrost>
If entity ever hangs on it own, we ban it
<mbrost>
start/stop/resubmit are still required, the WQ gives the option single or multi-threaded
tursulin has quit [Ping timeout: 480 seconds]
<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
<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/
<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
<mbrost>
and it probably would not work
swalker_ has joined #dri-devel
<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
swalker_ is now known as Guest412
<mbrost>
which in turn is how we find an possible entities that caused the entire GPU to hang and ban them
hansg has quit [Quit: Leaving]
Guest385 has quit [Remote host closed the connection]
<mbrost>
gotta run
mbrost has quit []
heat has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
Guest412 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
illwieckz has quit [Quit: I'll be back!]
<zmike>
anholt_: is there any sort of size limit on traces we use for ci?
jaganteki has joined #dri-devel
<anholt_>
Basically no. Like, if it's huge, it should be worth it.
<anholt_>
(see the README)
frieder has quit [Remote host closed the connection]
<zmike>
hmmm
<zmike>
I was considering a csgo trace, which I've trimmed down to one frame, but it's 1.2gb
<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)
<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.
jeeeun841351 has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
<zmike>
I've got a pretty big trace atm so I could easily cut 3 frames
<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...
<lumag>
The list of patches depending on this series starts to pile up on our side.
mvlad has quit [Remote host closed the connection]
dcz has quit [Ping timeout: 480 seconds]
nchery is now known as Guest432
nchery has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<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?
<airlied>
we've tended towards the latter
<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
<jenatali>
The other option is to try to get a waiver, or wait until the dependent component gets fixed
<jenatali>
That might be a while though :(
<airlied>
like if a user tries to use the feature and dxil validation blocks them, what's the point in exposing it?
<airlied>
but you aren't really meeting the requirement
<airlied>
since a user can't actaully use the feature in real life
<jenatali>
Yeah. Fair
<jenatali>
Sigh guess I play the waiting game then
<airlied>
don't you control the dxil validator as well?
<jenatali>
Kind of?
<jenatali>
Not my team
<airlied>
tear down those silos :-P
<jenatali>
Yeah I'm looking at my options
<airlied>
escalate to satya
<jenatali>
Heh. Our first layer of management in common is a bit below that level :)
<HdkR>
Just make the driver live patch the dxil validator to disable the overly-strict validation :P
<HdkR>
Didn't need those checks anyway
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
<jenatali>
Brilliant!
<jenatali>
I could ship a hacked version of the validator
<HdkR>
Anti-cheat over here raising an eyebrow from remapping RX to RWX
<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
<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)
<Lyude>
hm, maybe something's happening in drm_mode_set_crtcinfo() that I'm not accounting for
<airlied>
konstantin_, zmike : fair bit of CI side swiping with the descriptors MR, might want to make that the priority
<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
<airlied>
also adding that vulkan flag to NIR sets of alarm bells for appeals to higher gfxstrand
rasterman has quit [Quit: Gettin' stinky!]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
gouchi has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<emersion>
Lyude: positive/negative sync, VESA specs define what these mean
<emersion>
diagrams in EDID spec iirc
nchery has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
<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
<emersion>
you mean you can or cannot?
<emersion>
it's a free standard, can get it from their box.com
<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
<emersion>
there are diagrams e.g. in "3.12 Note Regarding Borders"
<Lyude>
haha, found it the second you posted that
<Lyude>
thanks :)
<emersion>
i think other standards had similar diagrams too
<emersion>
hm GTF has one but less detailed
<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?
<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
<Lyude>
the gears are slowly starting to turn…
pallavim has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
vliaskov_ has quit [Remote host closed the connection]
tak2hu[m] has joined #dri-devel
pcercuei has quit [Quit: dodo]
paulk-bis has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
Guest432 is now known as nchery
robmur01 has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]