ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
mikezackles has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
...drm_display_mode can't be subclassed sanely :|
<alyssa>
because "[get_modes] is only called... when the EDID isn't overridden through sysfs or the kernel commandline."
<alyssa>
=> I have to do an O(N) walk over the mode list at mode set time to lookup the magic IDs, as opposed to just casting drm_display_mode to dcp_display_mode and reading off the ID...
<alyssa>
then again im not sure how EDID overrides are supposed to work at all
gpuman has joined #dri-devel
gpuman___ has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
gpuman_ has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
gpuman___ has quit [Read error: Connection reset by peer]
gpuman has quit [Read error: Connection reset by peer]
gpuman has joined #dri-devel
gpuman_ has joined #dri-devel
sagar_ has joined #dri-devel
gpuman__ has joined #dri-devel
gpuman has quit [Remote host closed the connection]
Company has joined #dri-devel
The_Company has quit [Ping timeout: 480 seconds]
gpuman has joined #dri-devel
camus has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
mikezackles has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman has quit [Read error: Connection reset by peer]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
sagar_ has quit [Remote host closed the connection]
sagar_ has joined #dri-devel
JohnnyonFlame has joined #dri-devel
itoral has joined #dri-devel
mikezackles has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Hi-Angel has joined #dri-devel
jkrzyszt has joined #dri-devel
mlankhorst has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
rgallaispou has joined #dri-devel
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
Hi-Angel has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
dviola has quit [Quit: WeeChat 3.2.1]
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
<tpalli>
mesa/fdo ci having some problems with virgl jobs, they fail immediatly, cannot merge MR's
frieder has joined #dri-devel
lemonzest has joined #dri-devel
MrCooper_ is now known as MrCooper
rasterman has joined #dri-devel
<MrCooper>
tpalli: infrastructure issues should be reported on #freedesktop (I pinged the relevant folks there)
tursulin has joined #dri-devel
<tpalli>
MrCooper ok thanks
<jani>
mlankhorst: tzimmermann_: mripard: I was pushing -rc2 to drm-intel-fixes, got conflicts in drivers/gpu/drm/vc4/vc4_hdmi.c due to Linus reverting b1044a9b8100 ("Revert drm/vc4 hdmi runtime PM changes") and 31ad37bd6faf ("Revert "drm/vc4: hdmi: Remove drm_encoder->crtc usage"") directly in -rc2
<jani>
mlankhorst: tzimmermann_: mripard: I feel like I'm bound to screw up the resolution, could you look into it please? or get -rc2 in drm-misc-fixes too?
<jani>
danvet: airlied: fyi ^
gouchi has joined #dri-devel
gouchi has quit []
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<mripard>
jani: if I fix the conflict in drm-misc-fixes, will you be able to get the resolution with rerere, or do I need to fix it in drm-intel-fixes as well?
pcercuei has joined #dri-devel
Ahuj has joined #dri-devel
pnowack has quit [Quit: pnowack]
<jani>
mripard: the conflict's in merging drm-intel-fixes, because that's now the first one that brings in -rc2
<jani>
in drm-tip
<mripard>
what am I supposed to do then, I can't push to drm-intel-fixes
pnowack has joined #dri-devel
hansg has joined #dri-devel
<jani>
mripard: I don't want you to push to drm-intel-fixes
<jani>
mripard: afaict the two options are 1) rebase drm-misc-fixes on -rc2 or merge -rc2 to drm-misc-fixes, or 2) dim rebuild-tip and fix the conflict
<jani>
mripard: sure, I can try to do that, but I just fear I'm going to make matters worse
<mripard>
let me rebuild-tip then
<jani>
mripard: thanks
<mlankhorst>
jani: seems like someone with vc4 knowledge should look at
<jani>
mlankhorst: well, yeah, I decided I have no clue :)
<mripard>
jani: done
<jani>
mripard: *bows*
<mripard>
jani: sorry for the mess
<mripard>
apparently, we're expected to reply and fix bugs during the week-end or get reverted now.
<danvet>
mripard, yeah :-/
unrelentingtech has quit []
unrelentingtech has joined #dri-devel
<jani>
mripard: hey, no worries
txenoo has quit [Quit: Leaving]
Sachiel_ has joined #dri-devel
Sachiel has quit [Ping timeout: 480 seconds]
mranosta1 has quit [Remote host closed the connection]
mranostaj has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
hansg has quit [Remote host closed the connection]
xexaxo has quit [Remote host closed the connection]
xexaxo has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
<lynxeye>
flto: Do you remember if texture compares actually worked on GC3000 when you implemented them in etnaviv? pH5 didn't manage to get them to get them to work on a recent mesa.
alyssa has left #dri-devel [#dri-devel]
<flto>
lynxeye: not sure... I do remember it worked on GC7000L for D16_UNORM and D24_UNORM
Ahuj has quit [Ping timeout: 480 seconds]
<lynxeye>
flto: okay, thanks
<flto>
lynxeye: looks like I added code to etnaviv_texture_state.c (pre-GC7000L) for it, and made it halti>=2, so pretty sure it did work on halti>=2
iive has joined #dri-devel
itoral has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
agd5f has joined #dri-devel
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
<tagr>
karolherbst: sounds great, let me know if you have something that you want me to look at
<karolherbst>
tagr: yeah... I thought it might work, but actually didn't in the end
<karolherbst>
I think it's unfixable actually
<karolherbst>
Tegra would have to track the ref count st/mesa tracks internally
<karolherbst>
which ... is not possible without destroying all the benefits
<karolherbst>
tagr: but honestly.. you know my stance on the driver anyway and what I'd do, so if you want to have gallium changes, you should sort it out.
<tagr>
yeah, so the idea with that callback was to allow the driver to become aware of this tracking
<karolherbst>
and by the way.. this bug emerged as a Fedora Beta blocker which.. QE request a solution until Tuesday :)
<karolherbst>
tagr: yeah.. this isn't enough
<karolherbst>
I think
<tagr>
wow... realistic timelines
<karolherbst>
st/meas adjust the refcounts from time to time (mainly creating and destruction)
<karolherbst>
tagr: well...
<karolherbst>
without regular testing...
<karolherbst>
such issues come up quite late
<karolherbst>
the bug report is actually from mid August
<karolherbst>
I just got pinged on it last week
<karolherbst>
I am writing an email to discuss long term maintaince of the driver anyway, as I don't see this working as is
<karolherbst>
I had to deal with those blocers in fedora 33 and 34 as well.. so
<karolherbst>
and the blocker is quite high priority as gnome doesn't even start
<tagr>
karolherbst: we're just about ready to merge video decode support at the kernel level and we've got existing VAAPI userspace for that, but the plan is to move that support into Mesa, if we switch the tegra driver to the "standard" render-only model, I don't see how we can do that
<tagr>
I know that doing so would be easier, but then we basically restrict this to GPU functionality only, forever
<karolherbst>
it's not a technical problem
<tagr>
?
<karolherbst>
maybe I missed out a lot of work, but I don't see that Nvidia properly maintains this driver
<karolherbst>
and I am asking for this happening first before we are adding more stuff
<karolherbst>
it can't be that 2 out of three blockers are bugs being there for nearly a year
<karolherbst>
if you want to invest in this driver, do it properly
<tagr>
define properly
<karolherbst>
CI or full manual testing would be a start
<karolherbst>
look... it's not sustainable if this keeps from happening
<karolherbst>
and the bugs where on the wrapper level and if you want to keep it, those bugs should be caught earlier
<karolherbst>
I mean.. we can also just request you to deal with all of this, then I don't have to care
X-Scale has joined #dri-devel
<karolherbst>
you know, I think it's good having upstream open source support and everything, but it can't continue like this, that I got pinged on the day the release was moved a week because of this driver and I have to deal with this for a driver I would actually just replace by kmsro, and I still don't see we couldn't do the same thing with it
<karolherbst>
it's not like the tegra code would vanish, we'd just move it inside nouveau and remove the wrapper bits
<karolherbst>
(+ deal with the renderonly bits)
<tagr>
the renderonly bits always need to be in a "tegra" driver, because that's what DRI wants, can't just "bind" this to the Nouveau driver somehow
<karolherbst>
That one memory corruption is there for literally 8 months, and what should I think about that in terms of Nvidias dedication and commitment to this driver if they just use it to push for keeping IOCTLS they can use in their closed source stack
<karolherbst>
tagr: we can load other drivers in the loader arch
<karolherbst>
if we see tegra, we can load nouveau
<karolherbst>
no problem
<karolherbst>
radeonsi does the same
<tagr>
and the point is not that we couldn't achieve the same level of functionality as right now, but the problem is if we want to add additional support (such as offloading to other engines like VIC or NVDEC), then we're going to need some kind of wrapper again, so moving this to kmsro isn't really going to do much good
<karolherbst>
tagr: because you need it in your closed source stack
<karolherbst>
look, this wouldn't be an issue if those bugs are like a month old
<karolherbst>
but nearly a year? seriously?
<karolherbst>
and not a bit broken, but completly?
<karolherbst>
what should I think about all of this?
<tagr>
I'm not sure what closed source stack you think is using what IOCTLs
<tagr>
but none of the work I've done in the Mesa driver is in any way related to the closed source stack
<karolherbst>
Well.. if you want to keep the driver you have to show more commitment than that
X-Scale` has quit [Ping timeout: 480 seconds]
<karolherbst>
tagr: okay.. didn't know that. It's just the thinks I assume if it comes from Nvidia and all that.
<tagr>
the closed source stack doesn't use Nouveau and the only reason the "tegra" Mesa driver exists is so that we can use an upstream graphics stack on Tegra
<karolherbst>
well.. I'd use kmsro and deal with the specific things inside nouveau then
gpuman has quit [Remote host closed the connection]
<karolherbst>
I don't see why that shouldn't be possible
gpuman has joined #dri-devel
<karolherbst>
but if you say you already tried and it didn't work, okay, fine, but it's not sustainable if it keeps breaking and I have to deal with those blockers
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<karolherbst>
and I think we also have to talk about who "owns" the driver as in, is it Nvidia or is it some upstream Tegra community, or is it people related to nouveau?
<karolherbst>
All I know is, that driver was added because Nvidia needed it
<karolherbst>
if something changed there, then let's discuss this
<tagr>
"need" is perhaps not the right word
<karolherbst>
well.. I heard thinks and I tried to phrase it diplomatic
<karolherbst>
ly
<karolherbst>
*things
<karolherbst>
I don't want to say it was a bad idea back then, as it was more or less the only thing there
<tagr>
I'm not sure anyone within NVIDIA (other that perhaps myself) realizes that this driver is actually important, so if there's anything from your side that you can do to make that more obvious, perhaps that'd help with setting the right priorities
<karolherbst>
yeah... hence me writing an email to discuss this with Nvidia directly
<tagr>
is there some public bug tracker where these issues are being tracked? in the past #dri-devel has been the interface for that, but that's difficult to point people at
<karolherbst>
tagr: I think the point is rather, that not many people are actually using it, so bugs only appear last minute when a new Fedora release is getting tested or something
<tagr>
if there was some list of bugs that I could point people at, it might also become more tangible what work is needed and then things can be scoped
<karolherbst>
and bugs aren't the problem. Last minute release blockers which would be totally preventable by regular testing are.
<tagr>
that's a problem that we could solve with CI, so what would be the best way to integrate this in CI? do we need to ship hardware somewhere so that it can be hooked up? I had some discussions with someone a long time ago about this, so I'm not sure if things have changed
<karolherbst>
Well.. I don't even have time to hook up CI for nouveau
<karolherbst>
hardware isn't the issue here
<karolherbst>
people maintaining the CI system is what we need
<tagr>
back at the time, I think, there was a mechanism to hook up an external test farm to the CI, but after looking at that, that seemed impractical because we don't have anything internal that would meet (or at least be able to guarantee) the latency requirements
<karolherbst>
and I kind of expect Nvidia being able to provide this honestly
<karolherbst>
tagr: you can also just do daily runs
<karolherbst>
that's fine
<karolherbst>
we don't need pre-merge testing
<karolherbst>
if people merge stuff and we get to know a day late rit broke, that's already significantly better than the current situation
<tagr>
daily runs of what? building latest Mesa from git and running some test suite?
<karolherbst>
yes
<karolherbst>
I think anholt_ and others do something like this as a start, Fork mesa and have a scheduled CI run triggering some CI farm
<karolherbst>
and it just runs every day or so
<karolherbst>
and integrate it into our pre-merge infra laster once it is stable enough
Peste_Bubonica has quit [Quit: Leaving]
<karolherbst>
but it could also just trigger some nvidia URL which triggers internal CI stuff
<karolherbst>
I mean.. whatever would work for you
gpuman_ has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
<tagr>
let me first look at setting something up that can actually build Mesa and run a test suite, then we can think about how to trigger it
<karolherbst>
okay, cool
<tagr>
obviously, daily is easiest and we should be able to integrate that into our existing testing, but triggering is likely not the difficult part
<karolherbst>
sorry for being so direct on this, just.. I mean.. I want this to work and everything, so I get emotional on this, I just don't want to deal with this "yeah.. needs to be fixed asap" situation anymore
<tagr>
is there a standard test suite that would give us reasonable coverage? ideally something that can run offscreen, because I think the majority of the devices in the farm don't have a screen attached
<karolherbst>
tagr: yeah.. we use piglit and the CTS for some testing
<karolherbst>
there is a couple of test suite tempaltes inside the CI folde
<karolherbst>
r
<tagr>
and obviously it'd be somewhat awkward to validate visually anyway, I don't think we have things like the Chamelium
<karolherbst>
.gitlab-ci/container/
<karolherbst>
tagr: well.. the last two issues were memor corruption bugs because the Tegra driver wasn't updated or considered, so let's start with those low hanging fruits first
<tagr>
yeah, I think the display stuff is simple enough at the moment to not be a big problem, as long as offscreen rendering works we should be 95% (or more) functional
<tagr>
and no worries about being direct, it's much appreciated
<emersion>
igt doesn't require the chamelium
<emersion>
it just needs a way to get checksums from the hw
<tagr>
emersion: the problem with display checksums on Tegra is that nobody seems to know how exactly to compute them
mattrope has joined #dri-devel
<tagr>
so you're basically stuck with having to run a test once, inspect visually and then use the corresponding CRC as a golden reference
<tagr>
which is obviously something that can be done, but it's far from ideal
<karolherbst>
that bad? :/
<karolherbst>
I suspect the CRC bits in Tegra are completely different?
<karolherbst>
we have it wired up in nouveau, but...
<tagr>
karolherbst: do you know how to compute the correct CRC in software based on the framebuffer that you pass to hardware?
<emersion>
there's no need to know that
<emersion>
igt does it in two passes
<karolherbst>
I have no idea how that works, just that Lyude was working on it
<karolherbst>
emersion: old kernel/new kernel?
<emersion>
the first pass is used to display the expected result with KMS
<karolherbst>
ohhhh
<emersion>
the checksum is obtained from this
<emersion>
then igt sets up the real test (w/ scaling and planes and w/e)
<emersion>
and compares the checksum
<emersion>
maybe some tests do require a software impl of the checksum, but iirc at least *some*v tests use this startegy
<tagr>
emersion: but that then requires that the expected result displays correctly
<emersion>
if it displays incorrectly then the checksum should not match?
<tagr>
so for example if the format modifier passing is broken, then that won't give you the correct reference CRC
<emersion>
ofc if it's e.g. completely black then it won't work
<tagr>
okay, so it's primarily to test things like plane positioning, blending, etc.
<emersion>
yeah
<tagr>
gotcha
<emersion>
if your driver supports only one unscaled fullscreen plane, then it's not very useful
<tagr>
I was thinking more along the lines of actually verifying that your output was generating the right signal for a given input
<emersion>
yeah, that's impossible without somethinbg like chamelium
<tagr>
okay, I won't worry about that too much for now, then
DottorLeo has joined #dri-devel
<DottorLeo>
hi! what is the category for a Kaby Lake graphic bug on mesa?
<ajax>
DottorLeo: iris if this is gl, anv if it's vulkan
<DottorLeo>
ajax, thanks! It's an OpenGL game (Assault Android Cactus on Steam)
<DottorLeo>
i'll post a bug on on the bugtracker but just to tell quickly the problem is that the character on the main menu it's flashing quickly with black triangles on all the model ^^"
<DottorLeo>
and there is no such problem on a Sandybridge (that is using the old i965 driver i think)
gpuman__ has joined #dri-devel
gpuman___ has joined #dri-devel
<ajax>
might be interesting to try sandybridge using crocus as well
<kisak>
iirc, i965 supports kabylake, so if you suspect an iris-specific issue, you could try overriding the driver to i965 and see how the game reacts
<dolphin>
danvet: did the requested merge of tip/locking/wwmutex
<danvet>
dolphin, thx
gpuman_ has quit [Ping timeout: 480 seconds]
gpuman has quit [Ping timeout: 480 seconds]
<DottorLeo>
ajax, i've formatted that laptop with sandy :(
<DottorLeo>
kisak, how can i override?
<kisak>
MESA_LOADER_DRIVER_OVERRIDE=i965
Company has joined #dri-devel
mikezackles has joined #dri-devel
gpuman has joined #dri-devel
gpuman___ has quit [Remote host closed the connection]
<DottorLeo>
kisak, can i use the override command from steam on launch option? i've added it there but still the bug persist
<DottorLeo>
but i'm not sure that is using iris... it says driver i915
<DottorLeo>
is iris default on mesa 21.2.1
<DottorLeo>
?
<ccr>
what says?
<DottorLeo>
ccr, inxi
fxkamd has quit [Remote host closed the connection]
<MrCooper>
DottorLeo: if you add LIBGL_DEBUG=verbose it should say which Mesa driver it ends up using
<ccr>
sounds like it is reporting the kernel driver, not Mesa
<LaserEyess>
i915 is the kernelspaec driver, so that's not relevant, iirc iris because the default for gen 8+ in mesa 20, so for kabylake it would use that by default
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
<DottorLeo>
MrCooper, where should i put it? sorry i'm a bit new to debugging on linux
<LaserEyess>
export that env before running whatever game/binary you're running
<LaserEyess>
so `LIBGL_DEBUG=verboase ./my_thing` on a shell
<LaserEyess>
or in a wrapper script something like `export LIBGL_DEBUG=verbose && ./my_thing`
Duke`` has joined #dri-devel
<kisak>
DottorLeo: as far as I know, you can use it like any other environment variable in Steam.
gpuman_ has quit [Remote host closed the connection]
jessica_24 has joined #dri-devel
gpuman has joined #dri-devel
<DottorLeo>
ajax, thanks
JohnnyonFlame has joined #dri-devel
<mripard>
robclark: oh, I'm sure we can solve this with BPF :)
<robclark>
heh, ok.. I kinda assumed someone would have already realized that an -EPROBE_DEFER equiv of CONFIG_DEBUG_WW_MUTEX_SLOWPATH would be useful
<mripard>
I don't think we have something like this, sorry :/
<mripard>
especially since EPROBE_DEFER is becoming more and more irrelevant with the device links
<robclark>
well, I do see at least some probe-defer happening and things aren't exploding..
DottorLeo has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
gpuman_ has joined #dri-devel
gpuman__ has quit [Ping timeout: 480 seconds]
<mripard>
what is that WW_MUTEX_SLOWPATH option doing? always take the slow path of a ww mutex?
<mripard>
or is it random?
<robclark>
it is injecting random -EDEADLK
<robclark>
pretty good for testing ww_mutex backoff paths
<mripard>
yeah, I can imagine
<mripard>
I'm not sure we could do something like this with EPROBE_DEFER though, since there's not a finite list of functions that can return it
<robclark>
I think randomly skipping driver's ->probe() and pretending it returned -EPROBE_DEFER would work? (Or better, if there is some way to tell that some other driver depends on a given device, then only randomly defer dependent devices)?
<lynxeye>
robclark: Skipping driver probe could work, you just need to make sure to not introduce false starvation of the process. Probe of the devices on the deferred list is only attempted again when at least one driver probed okay in any given cycle.
<Lyude>
tagr: we don't-we just know that a CRC which isn't equal is likely a bug
<Lyude>
it's not good enough for everything of course, but it's good enough for many things
<robclark>
lynxeye: yeah, I think it would need to be done in driver core stuff so it could recognize the case and go thru the list again
<tagr>
Lyude: yeah, I think I was just starting from the wrong assumptions, but yeah, the way that emersion explained it earlier makes perfect sense
andrii82 has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
<andrii82>
Hello dri-devel community.
<andrii82>
I have a question regarding the correctness of the display unit operations. Suppose I have a dma buf with pixel data. I use synchronous drmModeSetCrtc or drmModeAtomicCommit with it and further wait on OUT_SYNC. After that, I want to update the pixel data of the mentioned buffer(I.e. I want to use only ONE buffer while interacting with DRM). Is it
<andrii82>
correct? Is it correct to update the buffer which is right now "inside DU", but the page flip already fired?
<ajax>
you can write to the buffer that's currently scanned out, assuming the driver lets you cpu-map it, or lets you send commands to it while it's in that state
<ajax>
it'll look bad and flickery if you're not careful about when you draw vs where the beam is, but it's a legal move
<robclark>
there is the additional complication of cmd-mode type panels (and I guess PSR would be kinda similar).. you may need to "flush" the updated fb
<mripard>
robclark: that would work for component-style drivers, but traditional ones could still get an EPROBE_DEFER in their probe and you wouldn't test their exit path
<robclark>
mripard: the idea is to test the probe path of some other driver which depends on the one that was randomly skipped
<robclark>
so kinda an indirect approach
<andrii82>
I wonder: is it correct that my updated pixel data is immediately displayed? (I don't know exact DU logic, but currently I see that)
<andrii82>
I.e. in other words: should DU continuously display/redraw the same buffer even if the user not sending drmModeSetCrtc or drmModeAtomicCommit?
mbrost has joined #dri-devel
<robclark>
andrii82: *typically* (ie. ignoring panels where you need to explicitly flush data to screen) the fb will be re-read each frame
<andrii82>
Ok. Thanks for the answers!
<robclark>
np
<robclark>
mripard: ok, I'm happy enough w/ my msm/dsi patch with bridges, so I added my s-o-b and re-pushed to my for-mripard/bridge-rework branch.. I guess the easiest thing would be for you to add that to your series? Hopefully jstultz or someone on his team can test with some dsi panels on some phone(s), which is the main remaining thing I'm worried about not being able to test myself
<jstultz>
robclark: amit pundir took a look but had some build issues against 5.15-rc2 and the kernel it was against has some other issue in his tree.. so don't have any data on it, but we'lre looking into it
<robclark>
jstultz: cool, thx..
lynxeye has quit [Quit: Leaving.]
marex has quit [Ping timeout: 480 seconds]
<mripard>
robclark: yeah, I'll take them in my series, thanks again
Ahuj has joined #dri-devel
<robclark>
mripard: fyi, I'm revisiting my NO_CONNECTOR series for ti-sn65dsi86 and msm/dsi.. which I think will conflict a bit in msm/dsi.. but depending on which order things land I can rebase one on the other or visa versa
gouchi has joined #dri-devel
andrii82 has quit [Ping timeout: 480 seconds]
tzimmermann_ has quit []
mbrost has quit [Read error: Connection reset by peer]
Hi-Angel has quit [Ping timeout: 480 seconds]
cedric has quit [Read error: No route to host]
cedric has joined #dri-devel
Danct12 has joined #dri-devel
cedric is now known as bluebugs
sagar_ has quit [Ping timeout: 480 seconds]
xexaxo has quit [Ping timeout: 480 seconds]
Sachiel_ is now known as Sachiel
ngcortes has joined #dri-devel
sagar_ has joined #dri-devel
gpuman_ has quit [Remote host closed the connection]
gpuman_ has joined #dri-devel
sylware has joined #dri-devel
<sylware>
hi, is there any mesa vulkan x11 dev around?
i-garrison has quit []
ngcortes_ has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
<sylware>
current git is not reporting VK_SUBOPTIMAL on vk_acquirenextimage properly
<sylware>
(the specs were fixed)
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
<sylware>
mattst88, yep, very probably, and the vulkan specs were fixed to make this behavior sound and clear
<sylware>
once the WSI window is not anymore a "perfect" fit for a swapchain, the vulkan implementation on a vk_acquirenextimage must report VK_SUBOPTIMAL
<sylware>
oh... wait, this is a fix? because I run radv mesa git and it still fails to return VK_SUBOPTIMAL on WSI window resize
idr has joined #dri-devel
<sylware>
mattst88, I cannot get the patch from the commit (I would test it) because of gitlab, could you https://paste.c-net.org/ me it? plz?
<mattst88>
ah, you can actually just append '.patch' to the end of the URL and it will give you a plain-text patch series that you can apply with git am
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
Bennett has joined #dri-devel
xexaxo has quit [Read error: Connection reset by peer]
Ahuj has quit [Ping timeout: 480 seconds]
xexaxo has joined #dri-devel
Hi-Angel has joined #dri-devel
<robclark>
pinchartl, dianders: btw, resurrecting the ti-sn65dsi86 NO_CONNECTOR support.. issue seems to be nothing is connecting the encoder to connector.. lmk if that rings a bell
Viciouss has quit [Quit: Ping timeout (120 seconds)]
Viciouss has joined #dri-devel
Bennett has quit []
Bennett has joined #dri-devel
rpigott has joined #dri-devel
columbarius has joined #dri-devel
Bennett has quit []
Bennett has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
rbrune has joined #dri-devel
<robclark>
oh, ok, I guess I'm meant to connect the connector/encoder myself
<Kayden>
so I think we need to add helgrind annotations to a bunch of our stuff :/
<Kayden>
things like threaded shader compiles...we access things from different threads without locking because the compile thread hasn't handed off the reference to the rest of the world yet
<Kayden>
but you can add some annotations on refcounts to teach it about it
<pinchartl>
robclark: you're supposed to create a connector, yes. the usual way to do that is to use the bridge connector helper
<Kayden>
I wonder if that sort of thing should go in pipe_reference?
<robclark>
Kayden: have you tried TSAN? I think at some point I gave up on helgrind..
<robclark>
pinchartl: yes, I was drm_bridge_connector_init().. but I wasn't drm_connector_attach_encoder() in that path..
<Kayden>
haven't looked at TSAN
<robclark>
I kinda assumed drm_bridge_connector_init() would do that for me
<robclark>
Kayden: I think the downside is needing a special build.. but at least for ASAN it is way faster than helgrind
<robclark>
IIRC the same is true for TSAN
<Kayden>
fast isn't a big concern for me currently, I just want to cut through all the noise so I can try and find any bugs
<Kayden>
it's worth a shot though..
<robclark>
tbf, the last time I tried helgrind was when I added the simple_mtx_t annotations.. and that was before TC and async-compile
<robclark>
I tried to clean up some of the other helgrind mesa noise (like one-time-init stuff), but some of that got reverted because I tried to do clever macro stuff that MSVC wasn't on-board with
<Kayden>
ugh :(
<Kayden>
that would've been nice to have
<robclark>
but that was pre-TC.. I'm not even sure what I'd do about TC..
<robclark>
Kayden: one vaguely related thing that has been useful for us is the compile time lock annotations.. ie. for things which can only be touched in TC driver thread vs things that can be accessed in front-end thread.. it does require building with llvm, but compile time checks are nice
<pinchartl>
robclark: maybe we should do it in the helper
<robclark>
yeah, perhaps.. fortunately there are fewer dsi hosts than bridges, so I guess that wouldn't be hard to change
Hi-Angel has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
pjakobsson_ has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
rbrune has quit [Ping timeout: 480 seconds]
gpuman__ has joined #dri-devel
gpuman_ has quit [Read error: Connection reset by peer]
gpuman has quit [Read error: Connection reset by peer]
gpuman_ has joined #dri-devel
macromorgan is now known as Guest445
Guest445 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
rpigott has quit [Ping timeout: 480 seconds]
rpigott has joined #dri-devel
pcercuei_ has quit []
Bennett has quit [Remote host closed the connection]
gpuman_ has quit [Read error: Connection reset by peer]
gpuman has joined #dri-devel
ngcortes_ has quit [Remote host closed the connection]
tursulin has quit [Read error: Connection reset by peer]
<Kayden>
anholt_: I tracked down which patch is causing consistent iris-apl-egl failures in gitlab CI in my series, and I'm really confused :(
<Kayden>
all it does is make a pipe_context at screen creation time
<Kayden>
at that stage in the series, the context is never used for anything at all
<Kayden>
it's only created and eventually destroyed
<Kayden>
I guess it could be a race in teardown or something, but... I would think all the real contexts and threads would have gone away by the time the -screen- is torn down...
iive has quit []
sagar_ has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
<anholt_>
Kayden: well, it looks like the commit is causing fence syncs to fail?
<anholt_>
so, are you mixing up some context for fences somehow?