<karolherbst>
and that's just the fails within the last two hours
<karolherbst>
not sure if that's the runner being flaky or something else, but those are hte only hangs within that time
<anholt_>
sorry, I don't have digging into this right now. hit up #freedesktop I guess.
<karolherbst>
on my current MR all virgl jobs on other runners work normally :(
<mareko>
can the runner be turned off?
<mareko>
and removed from the CI
<karolherbst>
I guess admins can?
<karolherbst>
finally managed to get my job on a different runner...
<karolherbst>
yeah.. and now it works
<karolherbst>
after I restarted it like ~6 times it always hung on the broken one
<karolherbst>
tarceri__: you want to restart the virgl jobs on your !18587 to move them to a different runner unless you want the stuff to timeout again
<karolherbst>
but it's true.. not all jobs hand on that runner
<karolherbst>
*hang
nchery_ has joined #dri-devel
nchery_ has quit []
nchery has quit [Read error: No route to host]
aravind has quit [Ping timeout: 480 seconds]
<mareko>
does any other driver plan to enable glthread?
<karolherbst>
I'd plan to do that in a newly written GL driver for nouveau
<mareko>
nvc0 rewrite? or a fork for ampere/ada?
<karolherbst>
nvc0 rewrite, but I doubt this is going to happen this year or next year... but I'd like to use more of those modern features (tc as well), but I don't think it's worth putting that effort into nvc0
<alyssa>
karolherbst: which driver?
<alyssa>
zink-on-nvk?
<alyssa>
that newly written GL driver for nouveau?
<alyssa>
I heard it's going to be a blast
<alyssa>
supports tc
<karolherbst>
:P maybe it will just be that
<karolherbst>
though not sure how much work it would be to enable glthread
<karolherbst>
nvc0 would probably benefit from it, because it currently busy waits on fences (uhhhh)
<karolherbst>
I rebuilt llvm with a different flag and now stuff doesn't want to link against spirv-tools anymore....
<karolherbst>
I am not sure if I should be mad or actually impressed
<mareko>
supporting tc is recommended before glthread
<karolherbst>
if a god exists, I am sure that one tries to convince me to just go stright with zink, and I don't listen
<karolherbst>
figures...
<zmike>
mareko: I've thought about it, but I don't have any data regarding always-on enablement
<mareko>
zmike: generally, drawoverhead is worse, everything else is better
<zmike>
it works fine when it's active though
<zmike>
hm
<karolherbst>
and I suspect supporting tc is a significant amount of work.. though maybe with fixed threading it wouldn't be too painful in nvc0
<karolherbst>
dunno
<alyssa>
karolherbst: as someone who really REALLY likes writing GL drivers
<alyssa>
starting a new GL driver in 2022 for VK capable hardware makes increasingly little sense
<karolherbst>
alyssa: you said you like writing GL drivers? I might have something for you there then
<zmike>
mareko: I guess I'll test some stuff out, but probably not for a couple weeks because xdc
<alyssa>
I have half a mind to scrap gallium/drivers/asahi
<zmike>
it'd just be a one-liner for me
<mareko>
tc isn't required for glthread
co1umbarius has joined #dri-devel
<karolherbst>
yo.. but I was also thinking of supporting TC in rusticl, but after thinking about it I concluded it makes 0 sense
<mareko>
you need 3 caps for good glthread perf: PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION, PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET, PIPE_CAP_MAP_UNSYNCHRONIZED_THREAD_SAFE
<zmike>
hm
<zmike>
not sure I have any of those
<zmike>
time to make a ticket so I don't forget
<mareko>
and ARB_buffer_storage
columbarius has quit [Ping timeout: 480 seconds]
<mareko>
the first 2 caps are needed by u_vbuf and GL in general
<zmike>
got that one
<karolherbst>
nvc0 has PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION
<karolherbst>
PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET seems to be not that much work, but maybe it would be? dunno
<karolherbst>
PIPE_CAP_MAP_UNSYNCHRONIZED_THREAD_SAFE is probably a noop here
<karolherbst>
but then again: performance and nouveau :'(
<zmike>
will check pipe caps tomorrow, probably all no-ops
<mhenning>
noob question: what is TC in this context?
<karolherbst>
threaded context
<mhenning>
ah
ngcortes has quit [Remote host closed the connection]
<karolherbst>
basically serializes all pipe_context interactions and offloads it to a thread if I am not mistaken
<mareko>
yes, but TC also behaves like a driver when it decides when to sync or not sync on buffer_map, etc. you could have a dumb buffer_map implementation in the driver and it wouldn't matter
<mareko>
glthread is not that smart
<karolherbst>
I already see it coming that I have to dig into TC one way or the other
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
<karolherbst>
llvm is the gift that keeps on giving....
<karolherbst>
so I literally only changed -DLLVM_ENABLE_EXPENSIVE_CHECKS to NO and mesa links again...
chip_x has quit [Remote host closed the connection]
mhenning has quit [Quit: mhenning]
<alyssa>
mareko: I wonder how "panfrost(no tc)" will compare in perf to "zink(tc)/panvk" ... ;-)
nchery has joined #dri-devel
yuq825 has joined #dri-devel
lemonzest has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
<mareko>
zink+anything is always an interesting combination
pallavim has joined #dri-devel
Ristovski has quit [Remote host closed the connection]
Ristovski has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
jrayhawk has quit [Quit: Lost terminal]
jrayhawk has joined #dri-devel
Company has quit [Quit: Leaving]
pallavim has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
bmodem has joined #dri-devel
<mareko>
also angle+anything
<HdkR>
That one is interesting in a different direction sadly
<mareko>
is angle android-only?
<HdkR>
No, it runs on pretty much everything
<HdkR>
Windows, Linux, MacOS, ChromeOS, Android, Fuchhsia, and apparently iOS is coming up
<mareko>
why a different direction then?
<HdkR>
Seems to performance quite badly in real games unlike Zink
<HdkR>
s/performance/perform
<mareko>
I see
<HdkR>
Also ES only means it is quite limited
<karolherbst>
but it's also always clearing any resource so you don't have data leaks, no?
<HdkR>
Hopefully only in a browser use-case then
<mareko>
I would expect Zink to beat ANGLE in CPU overhead, but GPU overhead?
<HdkR>
zmike: ^ Sounds like you need to find some GLES games to benchmark the two
<mareko>
most GLES benchmarks are CPU-bound on big GPUs, so they are not useful for GPU overhead testing
<karolherbst>
HdkR: question is, if there is a flag for it
<HdkR>
yea
<karolherbst>
but even on android you don't want apps to snoop memory of others
<karolherbst>
but maybe on android drivers are also required to not leak data
<HdkR>
...Where it is fine on Linux?
<karolherbst>
well.. nobody fixed it, so yeah, seems that way
<karolherbst>
:P
<clever>
karolherbst: that reminds me, i found a texture atlas cache in my minecraft folder years ago, in the undefined corners, i could see some memes i have browsed, and my irc client
<karolherbst>
if you allocate memory, it's not cleared
<karolherbst>
it's a huge security issue these days, but nobody cares
<clever>
karolherbst: more freaky though, if i reboot from windows to linux (dual boot), and then login, i briefly see the windows wallpaper on my desktop
<karolherbst>
nice....
<mareko>
radeonsi clears it if you're lucky to use DCC
<clever>
thats not just uncleared memory, thats USING uncleared memory to render
<clever>
i suspect a decent amount of that corruption is either the wrong tiling mode or the wrong stride
<karolherbst>
yeah
<clever>
and fragments being reused for other stuff
<karolherbst>
or overwritten parts
<karolherbst>
or something
<karolherbst>
still.. it's a kernel bug and should be fixed
<clever>
yeah
<karolherbst>
(in the kernel)
<clever>
i'm thinking, that the kernel should track what pages have been written to, and just deny reading back pages you havent written to
<clever>
or redirect those reads to /dev/zero
<karolherbst>
that's actually way too hard
<karolherbst>
because that would require scanning command buffers and stuff
<karolherbst>
the kernel allocates the physical memory anyway, and it could just track if it comes from a different process or not or something
<karolherbst>
and jsut clear it if it does
<mareko>
clever: try to put radeonsi_zerovram=true into /etc/environment and reboot
<mareko>
it only works with amdgpu
<karolherbst>
that doesn't fix the data leak problem though :P
<clever>
i assume thats implemented in userland and just memset's?
<karolherbst>
afaik the uapi has a flag to clear on allocation, but userspace can decide to not clear
<mareko>
clever: yes, but the memset is in the kernel
<karolherbst>
could probably patch the kernel to always clear
<karolherbst>
probably a one line thing
<mareko>
not recommended
<karolherbst>
yeah.. it needs some tracking to be low overhead
<clever>
i can see that wasting bandwidth
<mareko>
our clear implementation is very very slow
<mareko>
in the kernel
<karolherbst>
I suspect you don't want to run shaders in the kernel
<clever>
what if you have a list of image buffers, and when you allocate a buffer, tag it as un-initialized
<mareko>
I do, but nobody has done it yet :)
<clever>
but yeah, you still need to read the command stream, to know when something is rendered into the buffer...
<karolherbst>
:D
<karolherbst>
well.. in nouveau we actually use the accel engines, but we have that nice 2D engine still, so no need to actually run shaders
<clever>
at least on a dumb core like v3d, the command stream operates entirely on physical addresses
<clever>
so the kernel MUST parse the command stream, and replace object handles with addresses
<karolherbst>
we still build command buffers and all that stuff though
<karolherbst>
clever: yeah, but that's like super expensive
<karolherbst>
CPU bound games won't like that
<clever>
the rpi also has a nice sprite based 2d engine, you just give it the x/y/addr/stride of each image
<clever>
and it will dynamically composite it on the fly, racing ahead of the electron beam
<karolherbst>
anyway.. you only need to clear physical mem used by other processes and you could reuse memory for the same one and skip clearing
<karolherbst>
that shouldn't be all too bad then
<clever>
there is no framebuffer with the final image
<clever>
only the input buffers
<karolherbst>
anyway.. unless there is a nifty exploit and a high prio CVE filed, I guess nobody will fix it for real
<clever>
in the case of the leakage i found in minecraft, i would need to first un-scramble the images
<karolherbst>
that's why you use AI :P
<clever>
but its running under the same user with xorg, so the screenshot api is available
<karolherbst>
you need to parse the data anyway
<clever>
so i could just ignore gl and capture the screen directly
<karolherbst>
mhhhh... probably
<karolherbst>
do a screenshot every second :P
* clever
points to obs-studio
<karolherbst>
I think it would be more impressive to do that from a flatpak or something
<karolherbst>
have a shitty pay to win game you download from steam...
<karolherbst>
and it just collects credit card info, because why not
<zmike>
HdkR mareko: afaik it's the opposite: zink wins in gpu and overall but loses in cpu (due mainly to the total mismatch of gallium vertex api vs vulkan api)
<HdkR>
zmike: Neat!
<zmike>
on desktop anyway
<zmike>
zink doesn't fully support tilers yet
<clever>
karolherbst: surprisingly, i found a dead-simple way to gather online banking info, decades ago, when i was trying to only get my online banking app to work in my tablet, lol
<karolherbst>
...lol
<clever>
the hard part isnt gathering the info, its doing something with it after you have it
<karolherbst>
sure
<karolherbst>
but people are sensitive to leaked credit card info data
<clever>
basically, my local bank uses a google mapping library, to show nearby ATM's
<clever>
and that mapping library must be installed by the android oem
<clever>
amazon didnt include it on kindle
<clever>
so, i decompiled the banking app, removed the atm map support, and recompiled it, and boom, it just worked
<clever>
then i realized, how hard would it be to log the name/pw?
<clever>
i bet there are other kindle fire users, who also want this app
<clever>
pop it on amazons app store
<karolherbst>
the problem isn't snooping data from your devices, it's more complicated once you start doing it to others :P
<clever>
how well do they review their apps? could an outsider create an online banking app?
<karolherbst>
nope
<karolherbst>
well.. normally no, but some still get them in
aravind has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
<karolherbst>
thing is.. there are people checking those apps for fun and once you get noticed for being a fake app you get pulled
<clever>
yep
a-865 has quit [Ping timeout: 480 seconds]
<clever>
the other weirdness with that minecraft texture atlas
<clever>
ive heard elsewhere, that opengl should just be generating the atlas automatically
<clever>
so why is minecraft even having access to the full atlas, and why is it saving it to disk?
slattann has joined #dri-devel
yshui` has quit [Quit: Reconnecting]
yshui` has joined #dri-devel
<clever>
they are also stored in several LOD variants, 512x512, 256x256, 128, 64, and even 32
<clever>
the 32x32 atlas, is only 2x2 per texture!!
yshui` has quit []
yshui` has joined #dri-devel
<mareko>
GL doesn't have any atlas
<clever>
mareko: but might an implementation maybe batch several textures into an atlas to better utilize hw?
a-865 has joined #dri-devel
kts has joined #dri-devel
<mareko>
nope
kts has quit []
* clever
heads off to bed
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
nchery has quit [Quit: Leaving]
pcercuei has quit [Quit: dodo]
slattann has quit [Quit: Leaving.]
slattann has joined #dri-devel
bmodem1 has joined #dri-devel
<airlied>
alyssa: I do think you should scrap it
soreau has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
Duke`` has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
tzimmermann has joined #dri-devel
tzimmermann_ has joined #dri-devel
tzimmermann has quit [Read error: Connection reset by peer]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
itoral has joined #dri-devel
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
<mareko>
would zink->dozen make sense?
<airlied>
zink->moltenvk does, so why not
jewins has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem1 has quit [Read error: Connection reset by peer]
sdutt has quit [Read error: Connection reset by peer]
<javierm>
tzimmermann_: I was trying to get a dma-buf shared buffer between a v4l2 and DRM device but for example `gst-launch-1.0 v4l2src io-mode=4 ! kmssink` wouldn't work without format conversion
tzimmermann has joined #dri-devel
<tzimmermann>
javierm, of course there is.
<javierm>
since most v4l2 devices output YUV and ssd130x will only accept XRGB, so you need to use ! videoconvert
<tzimmermann>
but the code is wrong :)
<javierm>
oh, is it?
<tzimmermann>
the out_free label does mark the kfree statement
<javierm>
ohh, indeed LOL
<javierm>
tzimmermann: I meant to be before the kfree() but pasted in the wrong place
<tzimmermann>
and the call to drm_gem_fb_end_cpu_access should probably come after the update_rect function; even though it's not required
<javierm>
tzimmermann: I noticed that other drivers do end_cpu_access as soon as are done copying the buffer
<javierm>
but sure, no strong opinion on when to do it
<tzimmermann>
then just keep it like this, if you prefer it
<javierm>
tzimmermann: yeah, I like to keep things consistent with other drivers. I think it makes it easier to read
<javierm>
tzimmermann: I guess that if there would be a device that can output XRGB (i.e: a v4l2 mem2mem HW decoder maybe?) then you could use dma-buf to display without copying the buffers
<javierm>
tzimmermann: which is also a valid use case for your simpledrm patch
<tzimmermann>
yes
<tzimmermann>
i'm busy ATM. if you post the patch, i'll review later
<javierm>
tzimmermann: sure. Just wanted to know your thoughts about its value. Thanks!
rasterman has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
lynxeye has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
swalker_ has joined #dri-devel
any1 has joined #dri-devel
swalker_ is now known as Guest1529
<tzimmermann>
javierm, we should add such logic to all affected drivers IMHO
<javierm>
tzimmermann: agreed
<javierm>
tzimmermann: maybe you can post a patch to todo.rst? Seems to be a good janitorial task
pH5 has joined #dri-devel
swalker__ has joined #dri-devel
<tzimmermann>
well, there's more to it IMHO. we'd ideally have new plane_helpers begin_access and end_access. those would be called from the commit tail before/after a plane update.
<tzimmermann>
they'd do the drm_gem_fb_begin_access and the vmap things
<javierm>
tzimmermann: makes sense
Lynne has quit [Remote host closed the connection]
<tzimmermann>
we already have prepare_fb/release_fb. but release_fb is only called when the framebuffer is being replaced/removed on a plane. (i.e., at the next page flip)
<tzimmermann>
that's too late for drm_gem_fb_end_cpu_access
<tzimmermann>
maybe we should discuss such callbacks on dri-devel
<tzimmermann>
i also made a atomic_enable for plane helpers; as we talked about recently. there aren't many users of this, but its nicer for the few that use it
<pq>
swick, emersion, I don't really mind a libdisplay-info release without a high-level API as long as the low-level API is clearly documented as something that compositors should use only when nothing else is possible, and it you really need to use it, please consider hard about improving the high-level API first.
<any1>
What exactly does the time stamp given to drmEventContext.page_flip_handler2 represent? I've noticed that it lags behind drm_vblank_event (according to perf record) by around 500µs on my system.
Guest1529 has quit [Ping timeout: 480 seconds]
bmodem has quit []
fahien has joined #dri-devel
<emersion>
any1: it's supposed to be the time at which the first pixel of the frame hits the screen
<pq>
emersion, swick, I have no objections if you want to mark the low-level API stable now and do a release. I believe it's a reflection of the EDID spec, so it's hard to imagine breaking changes, since I think you addressed extensibility fine. But also because I don't really know that API much.
Lucretia has quit [Ping timeout: 480 seconds]
Lynne has joined #dri-devel
<pq>
emersion, swick, I'm fine with statically linking libdisplay-info into Weston, too, until it matures more.
bmodem has joined #dri-devel
<any1>
emersion: Is there a similar event that can tell me when the kernel starts processing vblank?
<emersion>
you mean, when the driver starts programming the hardware?
<emersion>
wouldn't that be right at atomic commit time?
<any1>
Yeah, that's probably a better place
Leopold_ has joined #dri-devel
<any1>
mmmm, well, I'm wondering about the deadline for the gpu to finish rendering
<emersion>
i don't believe any deadline is exposed at the moment
<vsyrjala>
the deadline is when the event gets emitted
<vsyrjala>
well, ignoring irq latencies/etc.
<any1>
vsyrjala: That's what I thought. Thanks.. :)
<emersion>
i mean, it's already too late when the event gets emitted, no?
Leopold_ has quit [Remote host closed the connection]
<emersion>
if you define the deadline as "the absolute last instant when a page-flip can still make it"
<vsyrjala>
yes, you need to guesstimate some kind of earlier useful deadline
<emersion>
makes sense
<emersion>
any1: i wonder if we can easily detect missed frames
<any1>
emersion: we can
<emersion>
any1: maybe with the presentation seq
<emersion>
any1: also need to be careful about VRR
<any1>
emersion: Maybe we can add 100µs to the delay every time that a missed frame is detected?
vliaskov has joined #dri-devel
Leopold_ has joined #dri-devel
<emersion>
we probably should yeah. make sure the delay doesn't get out of hand, and have a plan to reduce back the delay...
<emersion>
hm
<emersion>
that sounds a bit complicated
<any1>
I'd say cap it at 2ms
<emersion>
I'd prefer not to assume 2ms represents anything
<emersion>
because this behaves poorly with high refresh ratea
<emersion>
rates*
<vsyrjala>
could max (whatever that is) it on a miss, and then let it converge slowly towards some sweet spot?
<vsyrjala>
i guess you'd still want the sweet spot to have a bit of buffer for small spikes
<any1>
Or we could just use the time at which the flip callback is received and find out how much of a delay there is between the kernel irq and the callback being received on a few systems and just make that the constant which is subtracted
<any1>
... ignoring the timestamp given to the callback
<any1>
For this purpose at least
<vsyrjala>
the latency is dynamic
<any1>
There's no reasonable upper limit?
<any1>
The best thing to do would be to add an event that can tell us the time at which the irq happened, right?
<vsyrjala>
well, there is irq latency which depends mostly on cpu c-states, someone could have disabled irqs for a bit which also causes latency, and to get the flip into the hardware you need to execute a bunch of code whch is subject to scheduler decisions/possibly lock contention/etc.
<vsyrjala>
and cpu speed of course
<vsyrjala>
the system isn't deterministic is what i'm saying i guess. and not all machines are the same
MajorBiscuit has joined #dri-devel
<any1>
So, ideally, for a good estimate of the upper limit of the deadline, we would have to sample a sliding window of deadline times and calculate the maximum jitter over that window
<emersion>
that's what my MR does, FWIW
<MrCooper>
any1, emersion: FWIW, see clutter/clutter/clutter-frame-clock.c:clutter_frame_clock_compute_max_render_time_us in mutter for how it handles that
<emersion>
mutter uses max(previous N render times) + 2ms
<emersion>
with a fallback of .875 * refresh period
<emersion>
ah, thanks for the MR link, hadn't seen that one
<any1>
emersion: Huh, I'll have to take a closer look at your MR. I thought we had established that there was no event which can give us the actual deadline.
<emersion>
any1: i mean the sliding window thing
<MrCooper>
right, though "render time" is actually the maximum of multiple values, mainly the GPU render time and CPU processing time
<emersion>
MrCooper: CPU time can be included in the GPU time
<emersion>
if you read the GPU clock at the start of rendering
<emersion>
any1 had this simplification idea
<vsyrjala>
you could calculate a timestamp for the start of vblank from the event timestamp. that would typically be the deadline to get the thing into the hardware
<vsyrjala>
assuming you actualy got the dotclock you asked for (or close enough)
<jadahl>
mdnavare: IIRC we concluded that i915 should configure itself so that VRR doesn't require modeset, but in a way that the maximum refresh rate is the one set as the selected mode. then we didn't agree on how to set modes with higher refresh rates, that would only be that high if vrr was toggled on
<any1>
vsyrjala: How? :)
<emersion>
vsyrjala: you mean clock_gettime()+refresh_period when we get the event?
<emersion>
the event timestamp itself can be in the past or the future
<emersion>
this is page_flip_handler we're talking about right?
<vsyrjala>
the even timestamp is for the first active pixel. just subtract the vblank length from it
<emersion>
vblank length?
<emersion>
you mean pixel_clock * vblank_sync_width?
<emersion>
err
<emersion>
pixel_clock * vert_sync_width?
* emersion
doesn't remember the vblank graph very well
<pinchartl>
when COLOR_ENCODING and COLOR_RANGE are not exposed by a plane, what is the expected default YCbCr encoding and quantization range ?
alyssa has left #dri-devel [#dri-devel]
<pq>
pinchartl, I would have no idea. I think I just wouldn't even try to use it if I cared about those.
<pinchartl>
ok :-)
<pinchartl>
so it's best to be explicit in drivers
fxkamd has joined #dri-devel
<emersion>
it would probably be worth it to expose these props even with a single possible enum value
<emersion>
just to let user-space know what's up
bmodem has joined #dri-devel
<pinchartl>
marex: I'm looking at the lcdif driver and the RGB to YUV conversion. the driver hardcodes BT.601 coefficients with a full quantization range. doesn't HDMI use limited range for YUV ?
<zmike>
mareko: close the perf gap? but why would you make your driver slower?
<vsyrjala>
pinchartl: default is limited. i *think* the ycc quantization range knobs should apply to all ycbcr formats though, so in some cases you can override it
<vsyrjala>
on a related note, cta-861-h apparently makes selectable quantization range mandatory \o/
<pinchartl>
oh my... :-)
<vsyrjala>
now we just have to wait a few decades for actual imlementations catch up
<pinchartl>
I'll start simple with just one supported option, and expose it to userspace through the COLOR_ENCODING and COLOR_RANGE properties. more options can be added later
<pq>
sounds fine to me
kts has joined #dri-devel
<vsyrjala>
lol. cta-861-h blames *sources* for not following the standard. we follow it in i915, and it's half the *sinks* that don't follow it
<vsyrjala>
i wonder if we should really consider a quirk for it... the list will be massive
<vsyrjala>
either that or we add more heuristics. but my only idea left is to check the monitor name descriptor for the string "TV"
kts has quit [Quit: Konversation terminated!]
<swick>
pretty sure that some modes default to limited and some to full
Labnan[m] has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
Surkow|laptop has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
fdo ded?
<swick>
works for me
<JoshuaAshton>
oh its back now
<JoshuaAshton>
still cant push tho
<JoshuaAshton>
remote: GitLab: Internal API unreachable
Surkow|laptop has joined #dri-devel
jewins has joined #dri-devel
Haaninjo has joined #dri-devel
mlankhorst has quit [Quit: Reconnecting]
mlankhorst has joined #dri-devel
dakr has joined #dri-devel
gawin has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
cengiz_io_ has joined #dri-devel
alanc has joined #dri-devel
cengiz_io has quit [Ping timeout: 480 seconds]
<mdnavare>
jadahl: vsyrjala: So at init, always compute VRR parameters vmn, vmax, flipline based on the timings of the requested mode whenever a mode is requested. And only on the flip with VRR enabe requested is when we set vrr en reg and push to terminate vblank appropriately assuming now there is no mode change
Danct12 has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
<illwieckz>
zmike, it looks like lavapipe now builds without patch, so I closed the MR, but I don't know what fixed it. mesa/src/vulkan/wsi/meson.build already had dep_libudev since almost a year so the bug was probably elsewhere
<zmike>
illwieckz: yeah no idea
<eric_engestrom>
illwieckz: I was also looking into that and couldn't figure out how the flag could be missing
<illwieckz>
unfortunately I have not written the commit I was building when I opened the MR so I will probably never know
<illwieckz>
git reflog should print the date when the commits are changed
devilhorns has quit []
<illwieckz>
oh WAIT
kem has joined #dri-devel
<illwieckz>
I may have a workaround in my env…
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
srslypascal has quit [Ping timeout: 480 seconds]
<karolherbst>
huh.. radeonsis nir to llvm code doesn't seem to understand "vec4 16 div ssa_22 = vec4 ssa_21.x, ssa_20.x, ssa_21.y, ssa_20.y" :(
<karolherbst>
is there some lowering code I might have to urn?
<ajax>
illwieckz: git-reflog takes all the options git-log does, try 'git reflog --pretty=medium'
<karolherbst>
*run
<illwieckz>
zmike, the bug is still there
<illwieckz>
I had a *FLAGS workaround in my env
<ajax>
or =full if you want both dates
gawin has joined #dri-devel
<illwieckz>
ajax, thanks, that will be useful in other cases =)
<illwieckz>
it looks like I won't bisect a fix today… as the bug is still there 😅️
<eric_engestrom>
illwieckz, ajax: or `git reflog --date=iso` to just add the dates
<illwieckz>
anyway ajax that seems to print the commit date
<illwieckz>
eric_engestrom, is it the date of checkout?
swalker__ has quit [Ping timeout: 480 seconds]
<ajax>
hmmmm.
<eric_engestrom>
no, the date when HEAD was moved to that commit
<eric_engestrom>
(I think? I'm not 100% sure actually)
<illwieckz>
eric_engestrom, yes, that's what I was looking for, maybe I was not clear, thank you very much!
<illwieckz>
the data I checkout a commit == the date when HEAD was moved to that commit
<illwieckz>
the date*
<ajax>
oh nice
<illwieckz>
that's very good to know
<eric_engestrom>
yeah, I just verified, it's the date when HEAD was moved
<illwieckz>
that's good!
fab has joined #dri-devel
<eric_engestrom>
illwieckz: are you on an old meson version? perhaps it's a meson bug, I seem to remember some issues with its handling of link_whole or something around that
whald has quit [Remote host closed the connection]
tursulin has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<illwieckz>
eric_engestrom, I'm on meson master
paulk has quit [Remote host closed the connection]
<qyliss>
Is dri-devel the place to report a userspace regression? And is there anything I should check prior to reporting, apart from checking whether drm-tip fixes it?
<qyliss>
(A userspace regression caused by a kernel change, that is)
<mareko>
karolherbst: it's not immediately obvious to me why it trips, the code looks correct
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<karolherbst>
ssa_27.y
<karolherbst>
swizzle is 1
<karolherbst>
src_compoennts is 1
<karolherbst>
src_component is set to 1 because it's a vec4
<mareko>
unpack_32_2x16_split_x should return vec1 16, this is a NIR bug
<karolherbst>
nope
<mareko>
no?
<karolherbst>
nir_opt_vectorize makes it to vec2
<karolherbst>
and radeonsi wants 16 bit things to be vec2
<karolherbst>
dunno if we want nir_opt_vectorize to skip over vectorizing unpack_32_2x16_split_y , but at least nir is doing what it is told, no?
<karolherbst>
si_vectorize_callback is the cb which deals with that
<mareko>
I see
<mareko>
ac_nir_to_llvm doesn't support vec2 unpack_32_2x16_split_x/y, and I wonder why it didn't crash there
<karolherbst>
mhh.. good question
<karolherbst>
I do have some other crashes and even GPU resets going on, so maybe it is indeed not caught
<karolherbst>
could check for nir_op_unpack_32_2x16_split_x in the callback and keep it scalar for now
<karolherbst>
and _y
<mareko>
yes
<mareko>
I think you need to build LLVM with LLVM_ENABLE_ASSERTIONS=ON to get a failure in unpack_32_2x16_split_* translation
<gawin>
if one of nir passes fails due to lack of pointcoords/texcoords, then is it better to debug why this doesn't work without them or try to implement them?
<pinchartl>
marex: that may be related indeed, but I think the coefficients also need to be changed
<pinchartl>
if I can figure it out, would you accept a patch that switches to limited range unconditionally ?
<marex>
pinchartl: only if it contains a Fixes: tag
Danct12 has joined #dri-devel
<pinchartl>
ok :-)
illwieckz_ has joined #dri-devel
illwieckz has quit [Read error: Connection reset by peer]
illwieckz_ has quit []
illwieckz has joined #dri-devel
<vsyrjala>
marex: why is bpf hepful? does it have a working crystal ball in there somewhere?
soreau has quit [Remote host closed the connection]
<mdnavare>
vsyrjala: I am going to start working on adding a debugfs node that taps into crtc_state->vrr.enable to indicate the status of vrr enable that userspace can tap on to check that when userspace requested VRR if it was turned on in the driver. Does this make sense?
<vsyrjala>
is there some reason you wouldn't get vrr if you have a vrr monitor?
dakr has quit [Read error: Connection reset by peer]
<mdnavare>
vsyrjala: No this is mainly for a bad userspace request to enable VRR on a non VRR monitor - Either we reject this or just indicate through crtc_state->vrr.enable
<vsyrjala>
but what does it have to do with debugfs?
dakr has joined #dri-devel
<mdnavare>
some way for userspace to tap in and check the status, or we could change the crtc vrr prop to be bidirectional and set that to indicate the status
<mdnavare>
what would be your recommendation here
<mdnavare>
since you suggested we should not reject the modeset
<vsyrjala>
why would userspace want to look into debugfs to confirm that it did something?
<mdnavare>
actually we would need to use the HW state readout since now we are thinking of switching to a design in i915 where we will always calculate VRR params and only enable in HW when requested directly in atomic tail
Leopold has joined #dri-devel
<mdnavare>
vsyrjala: So can we just set a prop to indicate the HW state of VRR to indicate that back to UMD?
nchery_ has joined #dri-devel
<vsyrjala>
again, what umd would want to know this and why?
<mdnavare>
vsyrjala: Dont you think its a good idea to somehow let the userspace know that the request was ignored and actually the result is not as expected because now userspace is expecting something else and kernel has done something else
<mdnavare>
vsyrjala: This simply came up through VRR negative testing
<vsyrjala>
if userspace is stupid enough to expect vrr when there is no vrr monitor then i think it deserves to suffer
nchery has quit [Ping timeout: 480 seconds]
<emersion>
mdnavare: fwiw, user-space can never rely on debugfs, because debugfs has no stable API promise and is only accessible by root
<emersion>
IOW, debugfs is for debugging, but cannot be used for more
Guest1427 is now known as pmoreau
<mdnavare>
emersion: Agree thanks!
<HdkR>
Should mesa enable GLVND by default these days since most distros enable it by default, and users doing self-building tend to forget to enable it?
<mdnavare>
vsyrjala: So you think kernel should not do anything to let userspace know that vrr was not enabled, no negative VRR testing needed in userspace?
<mdnavare>
vsyrjala: May be we can just add this negative test internally in vrr IGT so we can check that kernel is doing the right thing
<mdnavare>
vsyrjala: Okay on the other topic, I am going start making VRR kernel changes to always compute vrr params, ad then in atomic ommit tail is where it will check the vrr crtc prop and commit the VRR params to HW if this is set and then set push
<vsyrjala>
for testing just issue a few flips to make sure vrr gets properly enabled/disabled?
<mdnavare>
vsyrjala: well for testing we wanted to add a negative test that vrr doesnt get enabled if it is non VRR monitor but currently we have no means toc heck this
<vsyrjala>
you can flip and see if you get vrr or not
gawin has quit [Ping timeout: 480 seconds]
<vsyrjala>
no need to trust some software thing you read from somewhere when you can just probe the hardware behaviour
<emersion>
you mean by checking the event timestamps i assume
<mdnavare>
vsyrjala: So just issue a few flips and if the vblank event timestamps are all corresponding to same 60Hz and conclude vrr not enabled?
<emersion>
similarly to async flip tests
<mdnavare>
Yes emersion that is how I interpreted this, is this correct vsyrjala?
<anholt_>
for anyone else: if you see "Can't make sense of .rodata section mapping" from valgrind, that's valgrind choking on valid mold output, rerun your build with another linker.
<vsyrjala>
mdnavare: yeah, you can check the timestamps. and could also confirm the events were delivered at the right schedule more or less
<swick>
emersion: have you looked at the CVT stuff yet?
<vsyrjala>
starting to sound a bit like kms_flip...
<emersion>
swick: nope
<mdnavare>
vsyrjala: Yea cool got it, so no need for any kernel changes for negative testing, now the only change I have to work on is get rid of the crtc_state->vrr.enable , always compute params and in commit tail, check for crtc vrr enabled prop and then commit to HW and send push
cengiz_io has joined #dri-devel
<mdnavare>
so that full modeset not needed
<vsyrjala>
and someone needs to fix the bugs
<swick>
emersion: alright, I'll take a look then. last base edid feature \o/
<alyssa>
anholt_: giving noltis ffma a try on panfrost
cengiz_io has quit []
mbrost has quit [Ping timeout: 480 seconds]
<anholt_>
alyssa: so, things feel a little fragile with trying to get it to happen at the right point in late algebraic
gawin has joined #dri-devel
<anholt_>
some of which is: well, if you had those other late alg things expressed in noltis, then the right behavior would fall out without clever ordering.
<anholt_>
but we do some stuff in algebraic that you can't do in noltis (repeatedly apply this transform to slide a constant up a chain of fmuls), so this is not a silver bullet.
warpme___ has joined #dri-devel
<alyssa>
OK
<alyssa>
(I'm still in the "information gathering" phase of NOLTIS opinion formation)
<alyssa>
(So this is good to know)
jfalempe has quit [Ping timeout: 480 seconds]
alatiera has joined #dri-devel
<mdnavare>
Thanks a lot vsyrjala and emersion for VRR discussion
<ajax>
HdkR: probably
<HdkR>
blammo, PR opened. Let the bikeshedding occur
<eric_engestrom>
anholt_: for that .rodata problem, mold changed its behaviour in 1.5 to avoid this, so an alternative to changing linkers is to update it :)
<alyssa>
noltis ffma is a loss on valhall with the simple cost function, will need to investigate why I guess (and if I need a more tailored cost function?)
oneforall2 has quit [Remote host closed the connection]
nchery has joined #dri-devel
oneforall2 has joined #dri-devel
<gawin>
anholt_: amazing work, the amount of presubs on r300 is crazy
oneforall2 has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
nchery_ has quit [Ping timeout: 480 seconds]
<alyssa>
Regressions because I set has_fsub and copied the late/ffma/late pattern from ntt which doesn't work
<alyssa>
Reordered to ffma/late/late and the regressions go away
<alyssa>
that is a *very* slight win over main
<alyssa>
(but a loss compared to !18814)
<alyssa>
I'm honestly unsure what more sophisticated cost function I could use here, 1 FMA + 1 MOV is usually better than 1 FMUL + 1 FADD and the backend has lots of smarts to avoid the MOV in common cases
mvlad has quit [Remote host closed the connection]
<alyssa>
.
<alyssa>
.
ngcortes has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
oneforall2 has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<anholt_>
alyssa: interesting that you saw much of a difference compared to !18814 -- it seems like it should get the same answer that that MR did for the case the MR was trying to solve?
<ccr>
alyssa, perhaps you just need to ... (f)mull over this thing ..
<airlied>
hmm stk has a 1kx1k DXT3 cubemap, I think this why llvmpipe dislikes it
<zmike>
that's a big cubemap
<airlied>
and compressed
ngcortes has joined #dri-devel
<airlied>
for some reason two of the 12 threads I have here really hit decoding it
<anholt_>
skybox?
<airlied>
yeah probably
<airlied>
I'd consider in the past just always decompressing dxt upfront to rgba, but then was sad about memory consumption
<pinchartl>
marex: I figured out the difference between YUV and YCbCr in the LCDIF
<pinchartl>
it's related to how the U/Cb and V/Cr values are interpreted
<pinchartl>
for the LCDIF, YCbCr means that the Cb/Cr value range [0, 255] maps to [-0.5, +0.5] with 120 == 0.0
<pinchartl>
while YUV seems to interpret the 8-bit value as a signed integer
<pinchartl>
[0, 127] maps to [0.0, +0.5] and [128, 255] to [-0.5, 0.0[
<pinchartl>
(give or take the off-by-one errors on those calculations)
<pinchartl>
so what we need is YCbCr, not YUV
<pinchartl>
furthermore, there's an error in the RGB <- YUV equations in the documentation of CSC0_CTRL
<pinchartl>
the D1, D2 and D3 coefficients are added, not subtracted
<alyssa>
anholt_: guess I should look at the shaders !18814 helps and see why noltis isn't figuring it out
<alyssa>
I might still have a pass ordering problem, who knows
ybogdano has joined #dri-devel
<marex>
pinchartl: nice
<marex>
pinchartl: I am starting to feel like I cannot write a patch without bugs
<marex>
:)
<pinchartl>
do you know anyone who can ? :-)
<pinchartl>
and the driver correctly uses RGB2YCbCr, there was no bug there
<marex>
pinchartl: it might make sense to document the above findings in some comment to the patches you likely plan to submit
<pinchartl>
yep, I'll do so
<marex>
pinchartl: it seems like a useful information
<marex>
thanks
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<airlied>
okay the current cache code doesn't little to make stk happier
ahajda has quit [Ping timeout: 480 seconds]
danilo has joined #dri-devel
eukara has quit []
dakr has quit [Ping timeout: 480 seconds]
danilo has quit []
dakr has joined #dri-devel
Leopold___ has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.5]
iive has quit [Quit: They came for me...]
rasterman has quit [Quit: Gettin' stinky!]
vliaskov has quit [Remote host closed the connection]
lygstate has quit [Remote host closed the connection]
<airlied>
oh wow stk eventually rendered a scene
cheako has quit [Quit: Connection closed for inactivity]
<FLHerne>
hours per frame?
<airlied>
yeah it might have been about 40 minutes
<airlied>
I even can "drive" the car a little bit
<alyssa>
airlied: have you tried nitro?
<alyssa>
it speeds the car up a lot
<alyssa>
hit "n"
<alyssa>
should solve your performance problems
<airlied>
alyssa: I think it caused a shader recompile :-P
<alyssa>
okay but after that car go brrrr
bgs has joined #dri-devel
<ccr>
:]
digetx has quit [Ping timeout: 480 seconds]
<zmike>
airlied: so it sounds like you're hot in pursuit of that perf
gawin has quit [Remote host closed the connection]
<airlied>
zmike: the perp^Hf got away from me
Leopold_ has joined #dri-devel
<airlied>
by my metric of does it render eventually, this seems fine :-)
Leopold___ has quit [Ping timeout: 480 seconds]
<zmike>
oof
<airlied>
though it's wierd that every so often one or two of the fs rendering threads get so smashed, assuming they are rendering the skybox
<zmike>
and here I was hoping I'd have an actual app to test
<airlied>
the heaven demo is all anyone needs :-P
<zmike>
does that actually work on sw?
<airlied>
yes, it's how I wrote llvmpipe tessellation support
<airlied>
and inspired overlapping
<airlied>
overlapping took it from 2 spf to 1.5 spf :-P
<karolherbst>
though I suspect llvmpipe could be make signfiicantly faster there, though not sure by how much, and one really would have to want improve perf there :P
<airlied>
overlapping got most of the easy wins, once the frag shader hits memory bw it's hard to move the needle