ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
columbarius has joined #dri-devel
quantum5 has joined #dri-devel
xyene has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Company has quit [Quit: Leaving]
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
tarceri has joined #dri-devel
pendingchaos_ is now known as pendingchaos
shashank1202 has joined #dri-devel
sukualam has joined #dri-devel
sukualam has quit [Quit: Quit]
sukualam has joined #dri-devel
sukualam has quit [Ping timeout: 480 seconds]
<graphitemaster>
So, if the AMDGPU KMD supports MCBP mainly for virtualization, what's preventing the other KMDs from supporting it too. I feel like once you have this part done, it's just a matter of handling the user-space side of things inside Mesa.
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
does drm_kms_helper_hotplug_event necessarily cause an atomic_flush()?
<alyssa>
it looks like it does for fbdev and mutter/xorg, but not for plain xorg
<alyssa>
(and doesn't for sway I think)
* alyssa
needs a flush to get something on screen after hotplug
mbrost has quit [Remote host closed the connection]
<alyssa>
thought userspace would always kick that, but no..
<alyssa>
I can't just call atomic_flush myself since I don't have the drm_atomic_state
<imirkin>
relying on userpsace to do things is always a losing proposition
<alyssa>
yeah, srsly..
<alyssa>
esp if the userspace in question is xorg..
<imirkin>
xorg is actually pretty reasonable...
<imirkin>
if you're having trouble with xorg, your expectations are off
<imirkin>
it's sorta the definition of correctness, for better or for worse, for the "legacy" kms api usage
<alyssa>
nod
<imirkin>
(i.e. non-atomic)
<imirkin>
[there were attempts to make it use atomic kms, but they were pretty half-hearted and deleted]
* alyssa
trying to understand how this possibly works for any other driver ..
<airlied>
alyssa: for xorg things should happen via atomic emulation I thought
<alyssa>
(then again id believe it if this exact use case is broken in some arm drivers)
<imirkin>
yeah, X doesn't call atomic_anything
<alyssa>
airlied: Emulation is working as promised
<imirkin>
if you're talking about exposure, X doesn't provide any exposure info
<airlied>
so the kernel should implement the legacy APIs via the atomic helpers stuff
<airlied>
alyssa: are you just running a bare X server?
<alyssa>
airlied: yeah, that's what's hitting this
<airlied>
alyssa: you need to run something on the X server like a DE
<alyssa>
(case of "send a hotplug to userspace but then nothing happens ===> black screen unless the user runs xrandr")
<alyssa>
xorg+i3
<airlied>
X doesn't deal with hotplug
<alyssa>
so this is a known broken wontfix situation that i've been struggling to debug for hours? lovely!
<imirkin>
X deals with a bit of hotplug...
<imirkin>
it'll pick up new connectors and stuff
<imirkin>
but it won't do anything other than making it available
<imirkin>
up to userspace to request stuff
<airlied>
Displayport is a bit too much for poor X
<airlied>
so X provides them to the clients
<imirkin>
some DE's will listen to those events and make use of the new items
orbea1 has joined #dri-devel
<alyssa>
airlied: fwiw "hotplug" in this case includes "power button on the monitor"
<airlied>
clients will get randr events
<airlied>
alyssa: yeah displayport will do that to you
<alyssa>
ah right yes this is a displayport upstream ugh
<imirkin>
airlied: you added the dynamic DP stuff to modesetting a while back though ... should work OK
* airlied
remembers keithp did some xrandr hacks
<airlied>
imirkin: the problem is with link negotiation etc
<imirkin>
and i copied it to nouveau :)
<imirkin>
hm?
<airlied>
like it works as long as you have a DE running
<imirkin>
or you run xrandr to tell Xorg what you want
<airlied>
but if you don't have a DE running and link training fails or other wierness
orbea has quit [Ping timeout: 480 seconds]
<airlied>
then you won't get an image
<imirkin>
yea of course
<imirkin>
why would you expect an image?
<airlied>
because it used to work with VGA :-P
<imirkin>
oh, if the primary is DP, and link training fails?
<imirkin>
then that's a very sad panda
<alyssa>
displayport is kinda sad
<alyssa>
for my understanding of the stack
<imirkin>
on the bright side, you can have hubs and loops
<airlied>
spanning tree, no loops for you :-P
<alyssa>
k it's definitely sleep o'clock
<airlied>
alyssa: I see a thing called autorander that might do it
<alyssa>
airlied: thanks for digging me out of the rabbit hole
* alyssa
opens gnome up again and goes back to not caring
<airlied>
I think I trolled keithp once about making xrandr --daemon be a thing for legacy users
<mareko>
anholt: not really, there's "umr -t" (v), which shows GPU memory usage for all processes, but all of them are labeled as Xorg, which is useless
<zmike>
jenatali: ping
<alyssa>
well, that's one more bug I can cross off my "blockers to sending the RFC to dri-devel" mental todo list
<jenatali>
Play around with it there instead of wasting CI's time ;)
<zmike>
this is a good idea
* zmike
has too many tools to keep track of
<jenatali>
IIRC it's a matter of changing alignment, switching between native 8-bit types (1-byte alignment) and bitfields of 32-bit types with 4-byte alignment breaks the bitfield packing
<zmike>
hm looks like changing the types gives it a size of 8?
<pq>
alyssa, why would you want to put something on the screen after hotplug, if userspace is not telling you to put something on that new screen? I mean, you don't. Or is that connector already lit up by userspace explicitly before it was connected?
<gawin>
not sure how about i915g, but for r300 saving any potential temporary is beneficial
lemonzest has joined #dri-devel
gpuman_ has joined #dri-devel
Danct12 has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
heat has quit [Remote host closed the connection]
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
JTL1 has joined #dri-devel
JTL is now known as Guest2710
JTL1 is now known as JTL
Guest2710 has quit [Ping timeout: 480 seconds]
JTL has quit []
JTL has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
<vsyrjala>
mripard: re: xdc talk igt dependencies. what big deps you mean? i think cairo and glib are the highest level ones
<vsyrjala>
honestly can't even remember why glib is required. maybe someone didn't want to hand roll a main loop or something
<vsyrjala>
so that could perhaps be nuked
JTL is now known as JTL1
<pinchartl>
if it's just for an event loop, libevent is nice
JTL1 has quit []
flacks has quit [Quit: Quitter]
JTL has joined #dri-devel
<pinchartl>
we use it in a libcamera demo application
<pinchartl>
(libcamera has a custom event loop though, maybe we could move that to libevent too)
flacks has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<vsyrjala>
g_hash_table,g_key_file,g_base64,g_regex,g_main_loop/g_io_channel so a bit more usage than i thought
<vsyrjala>
but i don't think glib should have a huge dependency list itself
pcercuei has joined #dri-devel
<vsyrjala>
or maybe i'm just out of date and it's implemented on top of a browser these days
<ccr>
wasm with emscripten, it is the modern way
lplc has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
<mripard>
vsyrjala: pixman is in there as well, python3 to some extent too
<danvet>
tzimmermann, [PATCH] fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list) <- do you plan to merge this?
<danvet>
probably good if we either merge right now, so that there's still enough soak time in linux-next before the merge window
<mripard>
vsyrjala: (even though pixman is probably a dependency of cairo already)
<danvet>
or wait after -rc6
<vsyrjala>
well, either you use cairo+pixman or you hand roll all software rendering
<vsyrjala>
pretty sure python should be totally optional
<danvet>
seanpaul, vsyrjala catching up on mails, but what did go boom with the DRM_MODESET_LOCK_ALL_BEGIN series?
<mripard>
danvet: I'm not sure I got the deal with the vc4 patches that got dropped in drm-misc-fixes, should I just reapply them or?
<danvet>
mripard, well they conflicted with linus' reverts
<danvet>
so direct reapply wont work
<danvet>
that's why they got dropped, since this was holding up everything else
<danvet>
plus some falling-through-cracks meant 1 month with no drm-misc-fixes pull, which isn't good
<vsyrjala>
danvet: wrong ww ctx used was the obvious fail. the other thing is no one reviewed things sufficiently to make sure dropping mode_config.mutex was ok
<vsyrjala>
also didn't go through ci, didn't get an ack from i915 maintainers
<vsyrjala>
ci caught the fail only after it got merged
<danvet>
ah yeah that sounds bad enough
<danvet>
I guess seanpaul got rusty :-)
<mripard>
danvet: ack, I'll reapply them and try to fix the conflicts then
<danvet>
jani, you checked that CI picked it up and enabled?
<jani>
danvet: no :]
<danvet>
jani, maybe do that, since I don't trust my own Kconfig simulator in the head :-)
<danvet>
CONFIG_DRM_DEBUG_MODESET_LOCK=y
<danvet>
jani, ^^ you're good, push it!
<danvet>
vsyrjala, I guess rip out the screaming macro and replace it with your magic block thing?
<danvet>
convice seanpaul, and ship it
gpuman has joined #dri-devel
<danvet>
imo consistency in this definitely trumps my bikeshed
<danvet>
consistency throughout drm I mean
gpuman_ has quit [Ping timeout: 480 seconds]
<tzimmermann>
danvet, i thought it was already
<tzimmermann>
but i can do
<danvet>
tzimmermann, tbh I haven't checked
<danvet>
looks like it's not there
<jani>
danvet: thanks
itoral has quit []
<karolherbst>
danvet: I think my idea was more to be able to play around with it without breaking mesa
<danvet>
karolherbst, yeah for that a local patch (or maybe even for dim) to s/Part-of:/Link:/ should do the job
<karolherbst>
yeah, not too much concerened about this part, but more about adding s-b-o tags from the person assigning to marge to merge it, etc...
<karolherbst>
I have no idea where we will arrive with this :)
<danvet>
karolherbst, hm right that sob sounds like a good idea
<danvet>
otoh it might be a bit much to do that implicitly like that with a button push
<danvet>
karolherbst, maybe just an acked-by tag
<danvet>
like Acked-by: danvet # approved merging
<karolherbst>
danvet: the issue I see is, that after merging somebodcy has to do the manual labour of adding those tags
<danvet>
sob it rather too formal maybe
<karolherbst>
yeah... but
<danvet>
karolherbst, yeah we'd need to hack up marge :-)
<karolherbst>
I mean.. today we add it through dim
<karolherbst>
at least for mboxes applied
muhomor has quit [Remote host closed the connection]
muhomor has joined #dri-devel
macromorgan has joined #dri-devel
xlei has quit [Ping timeout: 480 seconds]
jcline has quit [Quit: Bye.]
jcline has joined #dri-devel
muhomor has quit [Remote host closed the connection]
<alyssa>
pq: I.... guess I wouldn't...? It seems really weird to have the cables plugged in and working but have the "No signal" message on screen because userspace didn't do any mode sets
<pq>
alyssa, but that's how it works. Policy belongs in userspace.
<pq>
alyssa, what would you even display there, anyway?
<vsyrjala>
penguins!
<pq>
can't steal an FB from another CRTC
<pq>
alyssa, why would it say "no signal" though? Shouldn't the monitor go/stay in powersave/off?
yoslin has quit [Ping timeout: 480 seconds]
<alyssa>
uhhhhhh
<pq>
btw. I find the "power-off on DisplayPort looks like unplug" a blessing, much easier to test hotplug than ripping cables. :-)
<alyssa>
the reproducer is "using X over HDMI-over-DisplayPort, hit the monitor power off button, get some coffee, hit the monitor power on button"
<alyssa>
Yeah, truth
<pq>
alyssa, so the monitor was showing a good picture before it was unplugged and then hotplugged?
<alyssa>
Yeah
<pq>
ok, that's a quite different use case
<pq>
I thought this was about hotplug with nothing on the connector before.
<alyssa>
that use case works fine for Xorg with a DE, or with sway, or with Xorg if you type `xrandr --output HDMI-1 --mode 1920x1080` after powering on
<vsyrjala>
and then the monitor's firmware gets tangled up as usual and you need to pull out the power cord
<pq>
vsyrjala, that has never happened to me (until I got that HDR monitor for testing; it never survives a reboot of the *computer*).
<pq>
alyssa, right, The DE reacts to unplug and disables the CRTC/connector. Then it reacts to hotplug and enables CRTC/connector. When you don't have a DE reacting to things, it gets... annoying.
<alyssa>
nod
<pq>
alyssa, just like airlied said, from userspace perspective the CRTC/connector stays on after unplug if userspace does not deliberately turn it off.
<pq>
physically that probably cannot happen with DP? and HDMI?
<alyssa>
wait so do I need to fix this up in kernel space or not?
<pq>
(this is a long story...)
<alyssa>
(Is that Xorg-without-a-DE displayport hotplug case a bug in my kernel driver or Xorg breaking as intended?)
<pq>
When the monitor then comes back, the link training needs to happen again if it is going to display a picture again.
<pq>
who is responsible for triggering that is a good question
<vsyrjala>
hpd
<pq>
I suspect PC gfx card drivers see that the userspace state of the CRTC is still on, and seeing the hotplug (hpd) they try to re-traing the link and set everything up like it was.
<pq>
to make it work like it did in the VGA era
* alyssa
isn't really interested in making her shiny M1 work like the VGA era..
gpuman_ has joined #dri-devel
<vsyrjala>
though if you're lazy you could try the 'set link status prop=bad->fire uevent->let userspace trigger a full modeset"
<pq>
however, I could argue that setting link-status property to failed and not doing anything more automatically in the driver is just as good
<pq>
it may not fix the Xorg without DE use case, but who cares
<vsyrjala>
the ddx should handle it
<pq>
it does?
<alyssa>
so I should be using the link-status property here? even though the DCP firmware does all the link training transparently and the physical connector is an HDMI port because of course it is?
gpuman has quit [Ping timeout: 480 seconds]
<vsyrjala>
presuambly you should get some notification from the firmware that your link has dropped/come back
<pq>
alyssa, so what do you need atomic_flush for? :-)
<pq>
alyssa, listen to vsyrjala anyway, I'm completely on the other side of the UAPI.
<alyssa>
vsyrjala: yes, I have that notification, it's called "hotplug" :)
<alyssa>
(Amusingly the power off button doesn't generate any event, but powering on again generates hotplug(OFF) and then a moment later hotplug(ON) because DisplayPort..)
xlei has joined #dri-devel
<daniels>
yeah, both hotplug and link-status are a hint to the KMS user that it might want to do something about it
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Ahuj has quit [Ping timeout: 480 seconds]
el0y has joined #dri-devel
<danvet>
mlankhorst, will you review the i915 dma_resv_iter patches from könig?
ybogdano has quit [Read error: Connection reset by peer]
yoslin has joined #dri-devel
mattrope has joined #dri-devel
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
angular_mike__ has joined #dri-devel
<mlankhorst>
danvet: thought it was merged already?
<mlankhorst>
oh i915
<danvet>
yeah i915
<danvet>
I stamped all the others
<mlankhorst>
Yeah I'll look
<mlankhorst>
considering I had something similar
shashanks has joined #dri-devel
tarceri_ has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
Erandir has joined #dri-devel
soreau has joined #dri-devel
Duke`` has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
zack__ has left #dri-devel [#dri-devel]
zackr has joined #dri-devel
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
gpuman_ has quit [Read error: Connection reset by peer]
gpuman has joined #dri-devel
ddevault has quit [Remote host closed the connection]
ddevault has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
FireBurn has joined #dri-devel
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
ddevault has quit [Ping timeout: 480 seconds]
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
<FireBurn>
@agd5f any success in figureing out what's up with the new detection code?
rgallaispou has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
* alyssa
wonders who has to be poked for the drm/cma-helper commit to be applied
aravind has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
Lucretia has quit []
join_subline has quit [Ping timeout: 480 seconds]
ddevault has joined #dri-devel
ddevault has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
anujp has joined #dri-devel
ybogdano has joined #dri-devel
join_subline has joined #dri-devel
mattst88 has joined #dri-devel
gouchi has joined #dri-devel
<agd5f>
FireBurn, it's being investigated
frieder has quit [Remote host closed the connection]
<sravn>
danvet: there was push-back on the garbage collect fb scrolling due to all the old HW that only supports fbdev. Do we ignore the pushback?
<sravn>
danvet: I see tzimmermann (offline) already applied it - sigh
gpuman_ has joined #dri-devel
ddevault has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
ybogdano has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ddevault has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
moa is now known as bluebugs
<danvet>
sravn, there was also complaining on the patch which nuked scrolling, and it's not been reverted
<danvet>
so *shrug*
<danvet>
pinchartl, [PATCH v2] drm/cma-helper: Set VM_DONTEXPAND for mmap <- I thought you have one of these display blocks too?
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
<pinchartl>
IOMMU yes. not sure what VM_DONTEXPAND does though :-)
<pinchartl>
it's been a while since I last look at the IOMMU side, I've forgotten most of it
<pinchartl>
(still have to decide if that's a good or bad thing)
tobiasjakobi has joined #dri-devel
macromorgan has quit [Quit: Leaving]
macromorgan has joined #dri-devel
igor has joined #dri-devel
jewins has joined #dri-devel
<alyssa>
danvet: the issue is with IOMMU *and* CMA *and* not overriding functions
<alyssa>
the normal CMA drivers don't override but also don't have IOMMU
<alyssa>
the IOMMU drivers (rockchip, exynos, ...) override so don't hit this I think
<anarsoul>
why do you need CMA if you have IOMMU?
<alyssa>
anarsoul: what would you use instead?
<alyssa>
(see #dri-devel discussion from August about this.)
<anarsoul>
OK
<danvet>
pinchartl, apparently it splats somewhere
<anarsoul>
(I thought that you can construct virtually contiguous region with IOMMU...)
<alyssa>
anarsoul: the summary turned out to be "the C in CMA refers to device address space contiguous, not necessarily physically contiguous"
<alyssa>
and since the DMA API will use the IOMMU API internally instead of a carveout, everything works out
<danvet>
alyssa, rcar-du also splatting?
<alyssa>
though the docs/naming is confusing as hell
<alyssa>
danvet: rcar-du?
<danvet>
alyssa, that's pinchartl's driver
<anarsoul>
alyssa: interesting
<danvet>
I'm just wondering why no one complained about this before, your driver shouldn't be that special
<danvet>
alyssa, also what check goes boom?
<alyssa>
danvet: IIRC the check in drm_gem_mmap_obj goes boom `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND))`
<alyssa>
Robin found and fixed this independently for HDLCD
<alyssa>
I guess the "why has no one complained before" is that the popular drivers aren't affected
<danvet>
alyssa, ah I guess that explains maybe why no one is screaming
<danvet>
that is somewhat recent
<danvet>
so add Fixes: line and good?
<alyssa>
sure..
<danvet>
iirc that check is from this year
<danvet>
maybe pinchartl should look at what his driver does more :-)
<alyssa>
minor (i.e. driver still works but dmesg goes boom) regressions only affecting obscure hardware take time
<alyssa>
^for people to start complaining
<danvet>
alyssa, and when you have the Fixes: pls push it to drm-misc-fixes
<danvet>
dim fixes even formats the line correctly
* alyssa
doesn't have push
<alyssa>
git blame says the WARN_ON dates to Oct 2019
<alyssa>
but Arm hasn't done any work on hdlcd since May 2019 and I'm not convinced anyone outside Arm actually uses hdlcd so there's that ;)
<alyssa>
rcar-du looks like it might hit this boom
<pinchartl>
CMA is a very bad name here, we don't explicitly use CMA as such
<pinchartl>
CMA is the framework that made it possible to allocate physically contiguous memory
<pinchartl>
but it's all hidden by the DMA mapping API
<pinchartl>
we'll get DMA contiguous memory if there's an IOMMU, and physically contiguous memory if there isn't
<pinchartl>
and even in the latter case, there's no guarantee that CMA will actually be used in the backend
ddevault has joined #dri-devel
<pinchartl>
we shouldn't have named the helpers gem cma
mattst88_ has joined #dri-devel
<alyssa>
💯
FireBurnUK has joined #dri-devel
<pinchartl>
I haven't tested rcar-du + IOMMU in quite some time as, as far as I know, IOMMU support isn't enabled upstream on that platform
<alyssa>
danvet: ^ there you go then
FireBurn has quit [Read error: Connection reset by peer]
<pinchartl>
in theory it's an important use case :-)
mattst88 has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
<alyssa>
in theory, theory and practice are the same ;)
mattst88_ has quit []
mattst88 has joined #dri-devel
<danvet>
alyssa, hm I had no idea it was that old
<danvet>
but yeah if you add that as fixes: feel free to whack my ack on top and push
tobiasjakobi has quit [Remote host closed the connection]
<alyssa>
thanks :)
* alyssa
still doesn't have push but she can bother bbrezillon about that or something :p
<agd5f>
alyssa, you can get push if you want it
<alyssa>
sweaty guy with red button.jpg
<jekstrand>
tarceri_: What did you think of my suggested comment on !13166
gpuman has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
gpuman_ has quit [Ping timeout: 480 seconds]
gawin has quit [Remote host closed the connection]
<danvet>
alyssa, yeah go get that drm-misc commit thing
yoslin has quit [Remote host closed the connection]
yoslin has joined #dri-devel
ngcortes has joined #dri-devel
igor has quit []
lynxeye has quit []
Plagman has joined #dri-devel
boistordu has joined #dri-devel
xexaxo_ has joined #dri-devel
ngcortes has quit [Quit: Leaving]
ella-0_ has joined #dri-devel
ngcortes has joined #dri-devel
i-garrison has quit []
ella-0 has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
f11f13 has joined #dri-devel
f11f12 has quit [Ping timeout: 480 seconds]
<airlied>
we branched yet, I want to start landing disruptive stuff :-P
Ahuj has joined #dri-devel
<airlied>
ah I got rebased over a branchpoint :)
iive has joined #dri-devel
jljusten has quit [Quit: WeeChat 3.2.1]
jljusten has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
dongwonk has joined #dri-devel
<airlied>
yay finally got cl cts to pass a test with 128/64 images
sagar_ has quit [Read error: Connection reset by peer]
<zmike>
oh no
sagar_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: nice
<eric_engestrom>
airlied: yup, branchpoint done, -rc1 release incoming but you can land your disruptive stuff now :P
<eric_engestrom>
also yeah, sorry about !13328, I thought I could trick marge, but I feel like she's not doing anything anymore, I may have done something I shouldn't have :(
gouchi has quit [Remote host closed the connection]
<eric_engestrom>
or maybe she's just busy on some non-mesa repo?
<eric_engestrom>
daniels: if you're around, could you have a look just to be sure she's not stuck?
<eric_engestrom>
(ah, sorry about the ping, I just saw on #freedesktop you said you're on holiday this week, I didn't mean to bother you :)
igrtrrnt has joined #dri-devel
mbrost has joined #dri-devel
<kisak>
eric_engestrom: you can see the bot's activity log at https://gitlab.freedesktop.org/marge-bot . I've got a hunch that it'll unstuck itself after about an hour
<eric_engestrom>
yeah, but I'm not seeing any activity anymore, that's my point :(
gouchi has joined #dri-devel
<airlied>
yeah it does seem to be in the woods
danvet has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
pnowack has quit [Quit: pnowack]
Bennett has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<anholt>
marge should be back now
<anholt>
but x86 runners seem to be in short supply
<eric_engestrom>
I think it's because I just created two branches and two tags and it depleted the supply, but they should be back shortly
<anholt>
this whole week's been rough in my experience.
<pinchartl>
eric_engestrom: that was my Monday :-)
pushqrdx has quit [Ping timeout: 480 seconds]
pushqrdx has joined #dri-devel
ngcortes_ has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<anholt>
oof. spending 13% of gtest runtime on FilterTests when specifying each test by name in gtest_filter. check out PatternMatchesString for some entertainment.
<cmarcelo>
anholt: :-/ wonder if at least trying to shortcut patterns that don't have * and ? would be worth. (might need to split on : first for convenience)
ngcortes_ has quit []
ngcortes has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<anholt>
yeah, I expect that that would help a ton. but also the chain of "fix gtest -> get it into consumers" sounds not worth my time (yay C).
<jekstrand>
mareko: Does radeonsi use lower_atomics_to_ssbo or do you hook up the "real" HW atomics?
<airlied>
jekstrand: r600 has real hw atomics, don't think radeonsi does
<jekstrand>
airlied: Ok. r600 also doesn't use NIR yet. So maybe we can punt this problem a little bit?
<jekstrand>
hrm....
<jekstrand>
cmarcelo: ^^
<jekstrand>
cmarcelo: We may need nir_var_atomic
<airlied>
jekstrand: it doesn't use nir by default, it does have a working nir backend in the tree
* jekstrand
doesn't really like it but oh, well.
<jekstrand>
airlied: Right. Probably don't want to break it. :)
<anholt>
yeah, I think Gert was saying the r600 nir stuff was pretty close at this point?
<airlied>
I'm sure dschuermann would love to have a VLIW vs of aco :-
<airlied>
:-P
mbrost has joined #dri-devel
<cmarcelo>
jekstrand: maybe we'll need that...
<jekstrand>
cmarcelo: I doubt it'd be nearly as much of a pain as nir_var_mem_image
<jekstrand>
cmarcelo: Another option would be to make it a lowering pass and run it after atomics_as_ssbo
<Lyude>
agd5f, hwentlan - at least one of you two said that you didn't have any issue with breaking things in radeon.ko's (most likely already-broken) MST support correct?
<hwentlan>
Wouldn't have been me as I don't really deal with radeon.ko. You'd want agd5f's opinion on that
<Lyude>
gotcha
<Lyude>
yeah, now that I have time to look at things again I'm thinking about killing off as much of the non-atomic stuff in mst as I can
<Lyude>
also - marking things as deprecated (as in, using gcc's actual attributes for marking deprecated functions) isn't much of a thing in the kernel source is it?
<airlied>
nope not a thing at all
vivijim has quit [Ping timeout: 480 seconds]
<Lyude>
darn
<Lyude>
would like to do something to make sure people don't use older MST VCPI functions until I have a chance to remove them
<airlied>
Lyude: does anyone use them now other than radeon?
<Lyude>
nope
<airlied>
it's not like we are merging non-atomic drivers
<Lyude>
i just never really had the time to actually evaluate doing such a conversion before
<airlied>
atomic radeon would be fun :-P
mlankhorst has quit [Ping timeout: 480 seconds]
<Lyude>
(and if anyone does use those helpers, that's a bug)
<Lyude>
airlied: someday
<Lyude>
i still haven't even finished my hpd irq cleanup though
<airlied>
Lyude: there are a fair few places on the net saying to pass radeon.mst=1 to make somee things work
<airlied>
so it might not be great if it break
<Lyude>
airlied: tbh, I think I'm willing to take that risk as long as I can confirm that mst is as broken on radeon as we all think it is
<airlied>
Lyude: it used to work up the point of turning on dual-panel monitors, but often the second panel had different color levels
<Lyude>
not having to manage the mess of non-atomic and atomic state in the MST helpers would really simplify a bunch of code
<airlied>
you could fork into radeon the non-atomic and leave it die
<Lyude>
oooh, good point
<Lyude>
well, for the time being I think I'm happy with that plan - and will at least stop worrying about updating the non-atomic bits for the time being
* airlied
isn't sure I've got any MST hw to plug into a radeon at home
<Lyude>
I've got the MST hardware, but only a few radeons at home
<Lyude>
shouldn't be hard to find more though.
* airlied
only has docking stations, which I can't plug into radeon
<vsyrjala>
find the right pins and solder some wires
Kayden has quit [Quit: time to get off IRC for now]
<vsyrjala>
well, maybe there are easier ways to get mst hw
pushqrdx has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
Bennett has quit [Remote host closed the connection]
jani has quit [Remote host closed the connection]
jani has joined #dri-devel
__giggi__ has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
igrtrrnt has quit [Ping timeout: 480 seconds]
iive has quit []
sadlerap has joined #dri-devel
<agd5f>
Lyude, I don't recall ever getting radeon mst working, but it's been a while