<tomba>
I'm debugging weston crash (assert) when running with tidss. If I have this right, when tidss enables the crtc, drm_crtc_vblank_on() is called, and that leads to drm_reset_vblank_timestamp(), which does "t_vblank = 0;". tidss sends a vblank event with timestamp 0, and weston asserts that the new timestamp is bigger than the old one, and the new one in this case is 0, so smaller than the old one.
<tomba>
I can't figure out if this is a driver issue (but afaics it comes from the drm framework), or if weston should take timestamp 0 as invalid and ignore it.
<tomba>
I can make it work if I just remove the "t_vblank = 0;" part, as then a value from ktime_get() will be used. However, then weston reports "unexpectedly large timestamp jump (from 7646429 to 7664910)" when unblanking the display. So... weston expects the timestamp to only run when the display is enabled?
vliaskovitis has joined #dri-devel
<pq>
tomba, there are no "sometimes invalid" timestamps in KMS to my belief.
<tomba>
pq: the kernel has a comment "assign 0 for now, to mark the vblanktimestamp as invalid".
<pq>
tomba, the "unexpectedly large jump" is less of a problem. I don't recall exactly the conditions for that.
<tomba>
but maybe that 0 not supposed to go to the userspace. here it seems to go, though.
<tomba>
pq: I think it's just that before display blank, there are flip events with certain timestamps. then the display is blanked for a time, and when enabled, there's a flip event with much higher timestamp. so the diff between the previous and next timestamp is "unexpectely large". but, I have to say, I'm just guessing on what weston does here, I haven't looked.
<pq>
tomba, sounds reasonable.
<pq>
I don't think Weston ever blanks the display while waiting for a pageflip event. It cannot, really, since blanking is an atomic commit and userspace cannot commit until the previous commit has completed.
<pq>
Weston does have some code to try and fetch the latest vblank timestamp when it is preparing for an atomic commit after a pause.
<pq>
Weston wants the latest timestamp, so that it can predict when the next commit would complete, and to know if it can commit in time to meet the very next vblank.
<tomba>
The assert I see when enabling the display is "weston_output_finish_frame: Assertion `timespec_sub_to_nsec(stamp, &output->frame_time) >= 0' failed.".
<tomba>
pq: yep. I think that makes sense. but for some reason the kernel sets the timestamp to 0.
olivial_ has quit [Ping timeout: 480 seconds]
<pq>
yes, these are possibly to different problems. The timestamp going backwards should never happen from userspace perspective.
<pq>
*two
<tomba>
but only when the driver does drm_crtc_vblank_on(). then when we do "real" page flips, the timestamp is there.
<pq>
maybe the query for the latest vblank timestamp is somehow botched while the display is off?
<tomba>
it's just a ktime_get(). the timestamp is there, but because it's not a "high precision timestamp", the framework sets it to 0
zamundaaa[m] has joined #dri-devel
<zamundaaa[m]>
<pq> "tomba, there are no "sometimes..." <- Unfortunately in practice, things are different
<zamundaaa[m]>
amdgpu has a bug where it sends 0 for some pageflips, and out of tree drivers like the one for displaylink and the proprietary NVidia driver always send 0
<pq>
tomba, I think Weston does expect vblank timestamps to make progress during CRTC being off, but it also has code to deal with the timestamp being invalid for the query. The timestamp cannot be invalid for an actual flip though, even for the first flip on turning a CRTC on.
alarumbe has joined #dri-devel
<tomba>
pq: yep. I think that's reasonable. I can't figure out why the drm framework sets the timestamp to 0 on drm_crtc_vblank_on() call, and "reinitialize delayed at next vblank interrupt". I don't see how the ktime_get() timestamp is better at the vblank interrupt =)
<pq>
I guess vblank_on can be called at any phase of the scanout cycle, while the interrupt happens at a much better point of the cycle.
<pq>
*better known
<pq>
assuming the hardware continues to scan out even while vblank tracking is off
<tomba>
hmm perhaps... on the TI hardware, when we enable the crtc (and call drm_crtc_vblank_on()), the scanout cycle starts. so it's the zero point, so clear phase in the cycle.
<pq>
right, I think the difference is that a driver could disable vblank tracking even while the CRTC is scanning out, to conserve power when the interrupts are not necessary.
<pq>
so in that situation, it makes sense to wait for the interrupt when turning the interrupts on again, if the driver cannot determine the timestamp otherwise
<tomba>
yes, but I think that's different, it's handled with drm_crtc_vblank_get/put
<pq>
hmm, ok
<pq>
unfortunately I have no idea of the DRM kernel internals really
<pq>
so for your hardware, and for turning a CRTC on, you would really want to ktime_get() at the crtc enable time.
<pq>
can't you override the DRM core/helper behavior to achieve that?
<pq>
tomba, I hope I could give at least some clues here. Good hunting. :-)
<tomba>
pq: well, I can just comment out the t_vblank = 0; line =) and yes, I could reimplement drm_crtc_vblank_on(), but that migth be quite a lot. and to be honest, I don't see anything special with the TI hardware here, I would assume many other display subsystems behave the same. which makes me wonder what's wrong with tidss driver =)
frankbinns has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
<pq> "zamundaaa, should report bugs on..." <- For the proprietary NVidia driver, it's not possible to fix it afaik, something about missing symbols
<zamundaaa[m]>
amdgpu I of course filed a bug report already. What I'm saying is that it's best for compositors not to assert when it happens
jkrzyszt has joined #dri-devel
zzag_ has quit []
zzag has joined #dri-devel
rasterman has joined #dri-devel
pcercuei has joined #dri-devel
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
<cmeissl[m]>
I am trying to switch from mali to panfrost and while most things worked right away direct scan-out of wayland clients stopped working. It looks like creating the dumb buffer fails with EACCES. From what I can tell debugging the calls in mesa the kms_fd points to a render node of the display controller node, which is set by the wayland platform when receiving the default feedback. The ioctl DRM_IOCTL_MODE_CREATE_DUMB then fails because
<cmeissl[m]>
DRM_RENDER_ALLOW is not set and the device node is a render node.
<cmeissl[m]>
As a quick test I patched and re-compiled the kernel with DRM_RENDER_ALLOW for the dumb buffer ioctls.
<jenatali>
glehmann: I think you're right
tvc has quit [Quit: tvc]
<cmeissl[m]>
With DRM_RENDER_ALLOW direct scan-out works again, but that doesn't sound right?
tvc has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
guludo has joined #dri-devel
<daniels>
cmeissl[m]: presumably you're using a downstream kernel where either the mediatek or rockchip driver is patched to declare DRIVER_RENDER, despite not being able to do any rendering. nothing in the wider stack expects this. just patching that out should fix your problem completely.
Company has joined #dri-devel
<cmeissl[m]>
daniels: yeah, downstream kernel from mediatek (based on genio 510). already had to backport some stuff around AFBC, so I am not surprised that it might need more changes. will give it a try, thanks!
luc has joined #dri-devel
<daniels>
np
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
Calandracas_ has quit [Ping timeout: 480 seconds]
frankbinns1 has quit [Remote host closed the connection]
frankbinns1 has joined #dri-devel
phasta has quit [Quit: WeeChat 4.6.2]
luc has quit [Remote host closed the connection]
YuGiOhJCJ has quit []
bolson has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
jsa1 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
<cmeissl[m]>
jup, removing DRIVER_RENDER worked, thanks again :)
<cmeissl[m]>
btw, awesome work from everybody, especially for supporting the NV12 MTK Tiled format!
frankbinns2 has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
frankbinns1 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
rz_ has joined #dri-devel
rz has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
yshui has joined #dri-devel
yshui_ has quit [Ping timeout: 480 seconds]
Guest25913 has quit []
fab has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
frankbinns2 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
jsa1 has joined #dri-devel
frankbinns2 has joined #dri-devel
kts has quit [Read error: Connection reset by peer]
lsntvt__ has quit [Remote host closed the connection]
kts has joined #dri-devel
coldfeet has joined #dri-devel
jkrzyszt has quit [Quit: Konversation terminated!]
lsntvt has joined #dri-devel
chewitt has quit [Quit: Zzz..]
djbw has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
Coelacanthus[m] has joined #dri-devel
djbw has joined #dri-devel
<mlankhorst>
airlied: looking a bit at your cgroup series, doesn't look too different from what I was originally testing with xe against dmemcg
fab has quit [Quit: fab]
kts has quit [Quit: Konversation terminated!]
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
yepalee[m] has left #dri-devel [#dri-devel]
yogesh_mohan has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: leaving]
pcercuei has joined #dri-devel
pcercuei has quit []
pcercuei has joined #dri-devel
lsntvt has quit [Remote host closed the connection]