bcarvalho has quit [Read error: Connection reset by peer]
bcarvalho has joined #dri-devel
neonking has quit [Ping timeout: 480 seconds]
RAOFhehis[m] has quit []
chris[m]4 has joined #dri-devel
macromorgan has quit [Quit: Leaving]
mripard has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Ping timeout: 480 seconds]
idr has quit [Ping timeout: 480 seconds]
Lucretia has quit []
ServerStatsDiscoverertraveler4 has joined #dri-devel
boistordu_old has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
dhu1337[m] has joined #dri-devel
dhu1337[m] has left #dri-devel [#dri-devel]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
cphealy has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
RAOF has joined #dri-devel
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
bcarvalho_ has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
blue_penquin is now known as test
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
test is now known as blue_penquin
blue_penquin has quit [Quit: authenticating]
blue_penquin has joined #dri-devel
<RAOF>
Hm. With respect to EGL_KHR_platform_gbm, what should I expect CreatePlatformWindowSurface to do if I pass in a gbm_surface created from a different gbm_device (but with the same underlying DRM node)
<RAOF>
Also: What should I expect to happen if I pass in a gbm_surface created from a gbm_device on a *different* DRM node?
sagar_ has joined #dri-devel
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
aravind has joined #dri-devel
RAOF has quit [Quit: RAOF]
i-garrison has joined #dri-devel
RAOF_ has joined #dri-devel
gpoo has quit [Ping timeout: 480 seconds]
RAOF has joined #dri-devel
RAOF__ has joined #dri-devel
RAOF has quit []
RAOF_ has quit [Ping timeout: 480 seconds]
pekkari has joined #dri-devel
frieder has joined #dri-devel
uzi_ has quit []
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
Anorelsan has joined #dri-devel
thellstrom has joined #dri-devel
yk has quit [Ping timeout: 480 seconds]
<danvet>
airlied, [PATCH] drm/i915: Add relocation exceptions for two other platforms <- did you see my reply there?
jasuarez[m] has quit []
<airlied>
danvet: I did, I moved on, I just replied, just not sure what timeline for ADL-S coming out of alpha support
jasuarez has joined #dri-devel
<danvet>
airlied, the other lol is that for ehl/jsl it's still in force_probe mode and those are out since a while :-(
JimMorrison has joined #dri-devel
pochu has joined #dri-devel
mlankhorst has joined #dri-devel
Daanct12 has joined #dri-devel
pnowack has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
<pq>
berylline... gah.
yk has joined #dri-devel
tzimmermann has joined #dri-devel
pcercuei has joined #dri-devel
Lucretia has joined #dri-devel
thellstrom has joined #dri-devel
bcarvalho_ is now known as bcarvalho
i-garrison has quit []
i-garrison has joined #dri-devel
bcarvalho has quit [Read error: No route to host]
rasterman has joined #dri-devel
bcarvalho has joined #dri-devel
bjorn1 has joined #dri-devel
letoram has quit [Read error: Connection reset by peer]
<dolphin>
airlied, danvet: Any ETA for pulling -gt-next? We'd prefer to backmerge drm-next to pull in -rc2 and then some TTM changes
<danvet>
there's also a very mal-formed pull from tzimmermann for drm-misc-next
<danvet>
tzimmermann, ^^ btw I looked at this, doesn't parse at all, maybe just resend with all the things
<danvet>
dolphin, I guess if airlied doesn't get around to it then I'll do it tomorrow
<danvet>
airlied, applying -gt-next would also fix a linux-next fail because -gt-next is still not yet in linux-next someohw
JimMorrison has quit []
bjorn1 has quit []
letoram has joined #dri-devel
RAOF__ has quit [Ping timeout: 480 seconds]
<tanty>
daniels: thanks for the ping. I'm not directly managing the rpi's farm but I'll contact internally
<chema>
jasuarez is checking what is happened to ci24
gpoo has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
<daniels>
ah, it is jasuarez, thanks both!
<jasuarez>
thanks for warning!
<jasuarez>
I think we fixed the issue with that device
<jasuarez>
but still doing more testing
bcarvalho has quit [Quit: Leaving]
bcarvalho has joined #dri-devel
<jasuarez>
daniels: fixed the issue with igalia-ci24-rpi4-8gb
<daniels>
mslusarz: yes I do, it was an accidental deletion during a large spam sweep, I'm trying to see what I can restore
jasuarez has quit [Quit: authenticating]
jasuarez has joined #dri-devel
jasuarez has quit []
jasuarez has joined #dri-devel
<airlied>
danvet, dolphin : will process tmrw then
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
<dolphin>
airlied: thanks
<pcercuei>
narmstrong: RE: it66121, how do you configure the SoC's pin connected to the interrupt line? pull-up?
<narmstrong>
pcercuei: afaik no specific bias on the soc pin, simply set as IRQ_TYPE_LEVEL_LOW
<narmstrong>
pcercuei: let me check if there is a pull-up/dn on the pcb
<narmstrong>
pcercuei: nop, the int line is directly connected to the soc pin
<pcercuei>
narmstrong: the doc seems to say that the interrupt pin is either push-pull, or open-drain. By default it's open-drain though
<narmstrong>
pcercuei: maybe the soc has an internal pull-up enabled by default, let me check
aravind has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
<pcercuei>
the chip says that my input data is valid, but I get a suspiciously low number of interrupts (just one, and I don't get more when plugging/unplugging the cable again)
tzimmermann has quit []
tzimmermann has joined #dri-devel
Lightkey has quit [Ping timeout: 480 seconds]
Lightkey has joined #dri-devel
neonking__ has joined #dri-devel
vivijim has joined #dri-devel
<pcercuei>
narmstrong: I don't understand it66121_bridge_attach(). The code writes a set of registers, then at the end writes the reset register, so all the configured values are lost
<pcercuei>
If I configure IT66121_INT_REG for instance, it never shows anything but the default reset value in debugfs
vivijim has quit [Remote host closed the connection]
<narmstrong>
for interrupts, make sure your driver correctly enabled the HDP from the bridge, trace hpd_enable/hpd_disable
robert_mader has joined #dri-devel
<pcercuei>
I guess hotplug works, it looks correct when looking at modetest
<pcercuei>
My register 0x04 == 0x14, so the IT66121_SW_RST_VID is never cleared
<pcercuei>
It is actually cleared in it66121_configure_afe(), which is called correctly, so that's strange
<narmstrong>
pretty strange indeed
robert_mader has left #dri-devel [#dri-devel]
yk has quit [Remote host closed the connection]
yk has joined #dri-devel
<pcercuei>
I'm stupid, IT66121_SW_RST_VID is bit 3, so it is cleared
yk has quit [Remote host closed the connection]
iive has joined #dri-devel
enilflah has joined #dri-devel
boistordu_old has quit [Remote host closed the connection]
blue__penquin has joined #dri-devel
<pcercuei>
Could it be that I'm using a DVI monitor?
<danvet>
MrCooper, I read könig's 144Hz use case as "magic behind the compositor" and hence eglstreams instead of buffers
<MrCooper>
that's no longer Wayland then, and I'm not interested :)
<danvet>
MrCooper, well yeah it's a red herring for arguing that we need the compositor involved anyway to make this work properly
<danvet>
and at that poin trying to shoehorn it into implicit sync doesn't make much sense
<danvet>
at least all these discussion sound to me like amd trying to avoid touching compositors like the plague
<danvet>
which is also the fallacy intel loves to do
<MrCooper>
I agree that this trick can't work with implicit sync
<danvet>
anyway I didn't get around to my amdgpu hacks because I noticed a pile of issues in other drivers
<danvet>
plus a bunch of i915-gem fires :-/
<MrCooper>
not sure why sustaining 144 fps would be an issue TBH :)
<danvet>
so nothing really substantial from me aside from trolling and quips
<danvet>
MrCooper, I think it's 144 fps + lowest possible latency
<danvet>
hence why display hw decides at scanout which frame to pick
<danvet>
VR apparently cares enormously about worst case latency
<danvet>
but I guess for that stuff the answer is vk direct display and lease support on wayland
<MrCooper>
right, but VR currently means DRM lease anyway
<bnieuwenhuizen>
on VR I think it would be really awesome to combine that with conditional rendering instead of conditional pageflip
<danvet>
which again leads me towards "we should just fake dma_fence for these new userspace memory fence hw for winsys use"
<bnieuwenhuizen>
so you can do motion compensation if the frame misses
<danvet>
MrCooper, yeah exactly
<danvet>
we're not going to do 144fps ultra-low-latency through a wayland desktop
<danvet>
or well, there's much bigger fish to fry for that first, like the wakeup boost stuff
<danvet>
to not miss a ton of frames on first touch when idle
<danvet>
bnieuwenhuizen, btw for all these amdgpu discussion, I have notes here that make me believe it should all work, but I'm distracted from typing it up
<danvet>
maybe for next week
<MrCooper>
danvet: the mutter MR I pointed to allows for less than one refresh cycle client→scanout latency at 144 Hz, don't know if that's "ultra low" :)
<danvet>
MrCooper, ultra low I think is "scanout hw makes the call"
<danvet>
but yeah I think first we need to make amdgpu's dma-buf fd compliant
<danvet>
which is going to be some work unfortunately
<danvet>
I don't like building new stuff while we know the foundation is all sinking in quicksand
<danvet>
mripard, if you haven't, ff drm-misc-fixes
<danvet>
I should have a patch to push there soon
<MrCooper>
if it makes a difference whether it's the scanout HW or the kernel driver which makes the call, the timer which starts drawing a fallback frame better be ultra precise :)
<danvet>
MrCooper, yeah this entire stuff dies a bit on that little problem
<MrCooper>
(kernel using a hypothetical flip replace API)
<danvet>
plus 3d engines tend to take forever to preempt
<danvet>
bnieuwenhuizen, I guess the repro CS is done on the compute engines?
<bnieuwenhuizen>
yeah the VR motion stuff is done on compute with a high prio context
<bnieuwenhuizen>
VR aside if the game has a tight renderloop wayland compositors will likely need to invest into that as well
<bnieuwenhuizen>
since the game probably filled gfx work for the next frame when the compositor starts compositing
<MrCooper>
just need to make EGL_IMG_context_priority work, as is already the case with current Intel GPUs
<danvet>
yeah and preempting 3d is more a case of "good luck"
<danvet>
maybe you can get in after the next 3D_PRIM cmd (for i915, maps to draw calls in gl)
<bnieuwenhuizen>
when some postprocessing passes that are done with fullscreen quads can take a millescond or more that is not very nice for low latency stuff :(
<danvet>
hah, optimistic of you to assume we can preempt compute in that time
<MrCooper>
better than waiting for a whole frame :)
<bnieuwenhuizen>
oh definitely :)
<emersion>
bnieuwenhuizen, hopefully if it's a game then direct scan-out can be enabled
<swick>
so what exactly is it with gfx queues that they are so hard to preempt? or in other words why would doing the same work in compute be actually better?
<MrCooper>
emersion bnieuwenhuizen: yeah, in which case the compositor should be able to pick the next buffer ~1 ms before start of vblank now; if there was a flip replace KMS API, the compositor could send the next buffer to the kernel whenever it becomes ready
<MrCooper>
if not already when it gets the surface commit request from the client
<MrCooper>
swick: not sure there's still the same difference at the HW level with current AMD GPUs; the issue there is that the amdgpu kernel driver only exposes a single GFX queue, i.e. there's no preemption at all between graphics draws
<MrCooper>
so compute is the only way to preempt graphics drawing
<bnieuwenhuizen>
well on gfx10.3 they have premption
tzimmermann has quit []
tzimmermann has joined #dri-devel
<bnieuwenhuizen>
but compute is still far better on AMD because you don't have to preempt fixed function HW in the first place
<bnieuwenhuizen>
just need some free space on a CU
<swick>
you're still competing with other work on memory though when i.e. sampling textures?
<mripard>
danvet: I just pushed a ff of drm-misc-fixes to -rc4
<bnieuwenhuizen>
swick: that is what the priority is for to ensure your stuff gets done first :) (to some extent, obviously it doesn't get propagated everywhere)
<swick>
right
tzimmermann has quit []
<bnieuwenhuizen>
if you're doing this from an efficiency standpoint then the trick is often to do the compute stuff when the gfx queue is mostly busy doing fixed function stuff
tzimmermann has joined #dri-devel
<bnieuwenhuizen>
AFAIU shadowmap generation is a good moment for it typically
<swick>
well from a compositor pov we don't control any of that
<bnieuwenhuizen>
yeah but a compositor mostly would do it with high priority for latency reasons, not efficiency
<swick>
which is why I was wondering if/how big of an improvement a purely compute compositor would have
<MrCooper>
would be an interesting experiment
blue__penquin has quit []
<swick>
I suspect that the numbers would be kind of meaningless right now without proper client scheduling and just submitting work with dependency on unsignalled buffers
blue__penquin has joined #dri-devel
<bnieuwenhuizen>
if we are just submitting work without waiting on the fence first on the CPU we are much mess likely to hit the submission order inversion case
<emersion>
MrCooper, bnieuwenhuizen: gamescope is a purely compute compositor
<emersion>
ifb you want to do measurements
<emersion>
if*
<emersion>
gamescope also waits for client buffers to be ready
<MrCooper>
cool
<emersion>
and has a timer firing up close to vblank to submit frames to KMS
<eric_engestrom>
could you let me know if you think one of those is to blame? maybe it shouldn't be backported, maybe it's missing another backport?
<eric_engestrom>
I don't really have time to take a close look, so I'll probably just drop each one tomorrow and see if it fixes these tests
danvet has quit [Ping timeout: 480 seconds]
<kusma>
Just some unexpected pass, I think this was a patch zmuke forgot to cc stable that updated the results. I can take a look tomorrow morning and send a backport, thanks for the notice
<kusma>
Zmuke, that's your nick now
alyssa has joined #dri-devel
<alyssa>
RIP CI 2019-2021
<kusma>
?
<alyssa>
It's dead, jim
<kusma>
That's obviously not great...
cphealy has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<eric_engestrom>
kusma: thanks :)
gouchi has joined #dri-devel
rasterman has quit []
tzimmermann has quit [Quit: Leaving]
boistordu_ex has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
macromorgan_ has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
boistordu_ex has quit []
jewins__ has joined #dri-devel
jewins has joined #dri-devel
gouchi has quit [Remote host closed the connection]
boistordu_ex has joined #dri-devel
ngcortes has joined #dri-devel
HdkR has quit [Quit: Changing server]
boistordu_ex has quit [Remote host closed the connection]
HdkR has joined #dri-devel
pnowack has quit [Quit: pnowack]
boistordu_ex has joined #dri-devel
macromorgan_ has quit []
macromorgan has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
pcercuei has quit [Quit: dodo]
iive has quit []
bnieuwenhuizen has quit [Quit: Bye]
bnieuwenhuizen has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
CME_ has joined #dri-devel
karolherbst_ has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
sdutt has quit [Remote host closed the connection]
thellstrom has quit [Remote host closed the connection]
CME has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
sdutt has joined #dri-devel
ngcortes has quit [Remote host closed the connection]