ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
libv_ has joined #dri-devel
rcf has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
illwieckz has quit []
illwieckz has joined #dri-devel
tarceri has joined #dri-devel
<imirkin> anarsoul: i don't think it is =/
<imirkin> anarsoul: yeah, the proper thing would be to also be able to support storage_samples == 4
<imirkin> i.e. save/restore all 4 samples
<imirkin> but there's still no reason i see for depth/stencil to be special in this regard
<imirkin> (there are some super-advanced things which allow you to store color and zs at different rates, but you're not in that scenario... it's some AMD_advanced_something ext
<imirkin> robclark: you probably remember what the situation is wrt msaa winsys fb's and tilers?
<imirkin> the thing is that there's no real way to get at sample data in the winsys fb, so there's some leeway as to what you end up doing
<robclark> it is all about pipe_surface::nr_samples
<imirkin> robclark: does st/mesa set surface::nr_samples to 1 for such msaa buffers, assuming the PIPE_CAP is in place?
<imirkin> anarsoul: btw, obv util_blitter isn't going to be an appropriate resolve for you -- you should use the out-of-tile-mem resolve.
<robclark> iirc, conditional upon cap, it can set pipe_surface::nr_samples to something higher than the in memory representation of the surface
<imirkin> robclark: i mean specifically for the winsys fb
<imirkin> do you know if it does that?
<robclark> I guess winsys dependent?
<imirkin> hehe
<robclark> CrOS uses surfaceless.. so not entirely sure about other winsys.. but that can't isn't the gallium driver's concern
<robclark> s/can't/kinda/
<imirkin> yeah
<imirkin> i guess i'd have to dig a bit deeper, but doesn't look like winsys fb gets the multisample_render_to_texture treatment
<imirkin> but i wonder if it'd be ok to set storage samples == 1 there
<imirkin> (and importantly in renderbuffer_alloc_storage)
<robclark> does msrtt even come into play with "real" winsys buffers... iirc it doesn't
<imirkin> doesn't seem to. but it'd be nice if it did :)
<robclark> surfaceless does have some benefits from driver PoV ;-)
<imirkin> i guess the "invariance" rules sorta imply you can't do the insta-resolve on out-from-tile
<imirkin> i don't really see this addressed very strongly one way or the other in the ES2 spec
<imirkin> ES3 of course gains proper MSAA FBO's and such, so it will be much more explicit, but that's not the target here
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<imirkin> is there an ES ext that allows dynamic indexing into ssbo arrays? OES_gpu_shader5 only allows "constant integral expressions"
<HdkR> I don't think so
<imirkin> hmmm ... OH. but it's ok for images, and almost identical ops for them, so that should still work
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
pcercuei has quit [Quit: dodo]
alatiera has quit [Quit: The Lounge - https://thelounge.chat]
<rasterman> hmmm
<rasterman> so if i use drmVBlankReply events and the timestamp in it (tval_sec/usec)... that timestamp SHOULD follow the monotonic clock - right? last i checked at least one driver - it was reading the time from there... or seemed to... right?
<rasterman> so if you get this event sfrom the /dev/dri/card device... by the time you read it that timestamp MUST be <= "now" (if we get clock monotonic) ... right?
<robclark> rasterman: yeah, timestamps should be monotonic.. or at least I couldn't find an exception to that
<rasterman> well dang... this is the 2nd time i hit time weirdness with timestamps
<rasterman> i added a gotcha detect to handle where sometimes intel vblank timestamps go backwards...
Company has quit [Read error: No route to host]
<rasterman> and now on amdgpu ... acter fixing a problem with efl due to weston sending totally bogus timestamps in the future... (and ignoring future timestamps and relying on the monotonic clock and complaining bitterly when it happens)....
Company has joined #dri-devel
<rasterman> i'm seeing timestamps in the future from vblank events
<robclark> hmm, I guess drivers can screw it up.. maybe we need to define that better (since non-monotonic timestamps don't make sense when we (eventually) expose dma-fence deadlines to userspace)
<rasterman> like just a tiny bit in the future... like 0.00002255s is probably the worst ... mostly much less than that like 0.00000417s or 0.00000212s etc... but this far down the pipeline. like the dri device timestamp is read in a thread - then that thread sends that timestamp down a pipe to the mainloop and the mainloop uses that timestamp to "pretend" the now time is at this timestamp - because a vsync event woke the
<rasterman> look up and we want to pretend our timeline is synced to the vblank event for animation (thus at least in theory as long as the device is producing consistent perfect timestamps from hw... we can avoid some schedule jittering in animation and thus things like stuff panning across the screen pans at an exact rate despite schedule jitters because position is calculated based on this timestamp)
<rasterman> i suspect we have deeper "time screweyness" somewhere deep down. i shouldnt have to put code in to deetct time movign forward into the future in userspace .. but i'm having to to avoid some pretty ugly buglets...
<rasterman> and now i'm seeing it spewing out "i'm back to the future" errors a lot - like in streams... so ... hmm it's not a very rare "one off".
<rasterman> and there is a lot of lag between the drm event and by the time the mainloop gets to see it... so it's probably much futher in the future at the time the event is produced... :|
<rasterman> https://termbin.com/p4wp <- that's an example of how frequent it can be
<rasterman> anyway... was just confirming my assumptions were at least right. it shouldnt be able to go into the future.
tarceri_ has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
sdutt has joined #dri-devel
<vsyrjala> rasterman: the timestamp corresponds to the first active pixel of a frame. during vblank period it points to the future (the first active pixel of the next frame), and during active period it points to the past (first active pixel of the current frame)
<rasterman> vsyrjala: oh - so its not when the interrupt happened?
<vsyrjala> yeah. the design is based on GLX_OML_sync_control which says the timestamp will be corrected to match the first active pixel
alatiera has joined #dri-devel
<rasterman> makes sense... though not what i expected as timestamps normally mean when the event happenED (in the past) :)
<rasterman> well then... dang. that explains this
<HdkR> Spooky time travel logic
<rasterman> ya - you dont expect to see an event for a time ... in the future :)
mattrope has quit [Ping timeout: 480 seconds]
<vsyrjala> perhaps the most annoying thing about this is that it makes it a bit hard to come up with a deadline for submitting the next flip, since you don't know exactly when the previous event fired
<rasterman> yup
<rasterman> part of th idea of a vblank synced timer is to know when to wake up to render the next frame so assuming a budget of X you get the frame done just in time to show it :)
<rasterman> if you have no idea when that interrupt might happen ... ugh...
<vsyrjala> the best you can do i guess is to assume the flip latches on start of vblank, and then use the last even ts + length of active period to predict the next one
<rasterman> (of course a very busy system can't guarantee when this interrupt gets serviced but let's assume for now it's carefully set up so this thread is high priority and things are carefully set upt to not be that loaded in a normal usage pattern)
<rasterman> yeah - that's what i'm doing - or well a rougher approximation now. i thought this was the being of vblank timestamp and all my logic flowed on from that assumption ... so i now just have to pretend that is still the case and fiddle with the time :)
<vsyrjala> the driver (assuming it know what it's doing) can correct the timestamp to really match the point when the hw latches flips, even if the interrupt is delivered late
<vsyrjala> that's what we do now, except we do the correction to match the first active pixle
<rasterman> yeah - i read the code and saw it doing that correction ... but i didnt know it was going for first pixel - just i saw it correcting for interrupt handling latency to pretend the timestamp was exact :)
<rasterman> what might have been nicer for the kernel <-> userspace api in librm to report the timestmap, frame no AND the line or pixel point for the interrupt (perhaps also report the dotclock and width+height of total overscan region and other mode info). so the event has all the info for THAT specific interrupt and frame at that time for userspace to know when it triggered and then calculate it's own point from there. the
<rasterman> point being that it knows when the hw interrupt happens at any rate (and different hw may fire at different points)
<vsyrjala> yeah, or the event could carry two timestamps
<rasterman> at a minimum - yeah.
<rasterman> perhaps some exotic hw can do multiple interrupts per scanout, so you can ask it to eg nterrupt at start of vblank but also half way down the screen or at pixel x,y ... so if you have a known budget you could ask it to give you that screen interrupt rather than fake it with a cpu timer (based off a base interrupt)
<vsyrjala> there is certainly some hw (at least old hw, dunno about recent hw) that can fire an interrupt on arbitrary scanlines. but dunno if it makes sense to expose that since you can't generally rely on it being available
<vsyrjala> anyways, i suppose someone could propose a better vblank event if there's enough interest from compositor folks
<vsyrjala> emersion: jadahl: ^
<rasterman> well drm kernel infra could provide a helper than fakes it with a cpu clock timer...
<rasterman> or an ioctl to query how many interrupts available and if they can accept scan coords etc.
<rasterman> and some old hw was super exotic indeed... could do much more than just fire interrupts :)
<rasterman> those were funtimes.
<vsyrjala> operating in terms of scanlins/etc. can introduce a bit of extra error on since the actual dotclock could differ slightly from what the user requested. atm there is no way the kernel can inform userspace what the actual dotclock is
<rasterman> well you can calculate it over time based on interrupts i guess... :)
<rasterman> ZZzz...
rasterman has quit [Quit: Gettin' stinky!]
mclasen has quit [Ping timeout: 480 seconds]
LexSfX has quit []
sdutt has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<anarsoul> imirkin: so basically if I render to default fb with MSAA it'll result in explicit resolve somewhere later in mesa code?
<imirkin> anarsoul: well, so here's the thing ... forget about mesa for a second
<imirkin> just think about what information you need
<imirkin> so you have a 4x msaa fb
<imirkin> and you draw a polygon onto it
<imirkin> which covers some samples
<imirkin> you display that on the screen.
<imirkin> then you set up blending (in a way which considers the dest value)
<imirkin> and draw another polygon
<imirkin> if you've already resolved the original draw, then you won't get correct results, right?
<imirkin> so you need to have the full sample values ... i think.
<anarsoul> well, if there's a flush between two draws - yes
<imirkin> "display to screen" was my way of saying "flush", but yea
<anarsoul> imirkin: blob doesn't really care much about incremental drawing
<imirkin> ok, but you're not necessarily emulating the blob's bugs :)
<anarsoul> well
<imirkin> just coz blob does something doesn't make it right
<anarsoul> without these tricks MSAA is kinda useless on GPU of this class :)
<anarsoul> it just doesn't have enough memory bandwidth
<imirkin> yeah
<imirkin> so i wonder if you can instead "make it right" and properly represent this stuff
<imirkin> i.e. convince core mesa to request the driver to do a single storage sample
<imirkin> etc
<imirkin> MSAA on these GPUs really wants to do EXT_multisampled_render_to_texture
<anarsoul> well, I guess I'll implement it in lima in gallium way first
<anarsoul> and then I'll look into core mesa
<anarsoul> I need to get lima-specific blitter working first
<anarsoul> btw, are there any tests for blitter functionality?
<imirkin> well .... for ES2, you can't really blit these things
<imirkin> the only thing you can do is resolve
<imirkin> via glReadPixels and such
<imirkin> (or display the winsys buffer)
<anarsoul> well
<anarsoul> gallium driver still has to implement pipe_context->blit
agd5f has quit [Ping timeout: 480 seconds]
<anarsoul> isn't it used for resolve?
<imirkin> so ... the winsys fb is actually slightly special
<imirkin> very confusingly it uses the transfer function
<imirkin> not blit
<imirkin> at least for glReadPixels
YuGiOhJCJ has joined #dri-devel
<anarsoul> imirkin: so for default fb (is it winsys fb?) mesa has to do resolve on buffer swap. Where does it do that?
<imirkin> gooood question ... something like st_manager maybe?
<anarsoul> I think it's in dri_pipe_blit()
<anarsoul> src/gallium/frontends/dri/dri_drawable.c
<anarsoul> so it actually uses ctx->blit()
<imirkin> yeah, that seems likely
<imirkin> but glReadPixels uses the transfer call
<anarsoul> imirkin: do you mean I need to resolve in transfer_map()?
<imirkin> anarsoul: that's what glReadPixels calls. yes.
<anarsoul> I don't see vc4 doing resolve in transfer_map(), so it seems unlikely
<imirkin> it's a quirk of the API
<imirkin> probably you can't glReadPixels a MSAA winsys fb in ES
<imirkin> but you definitely can in desktop
<imirkin> many drivers don't handle this
<imirkin> i'm just pointing out that it's a thing :)
aravind has joined #dri-devel
aravind has quit []
<anarsoul> imirkin: well, assuming dri keeps msaa buffer and scanout separately, it's likely up to dri to handle that
<imirkin> glReadPixels only has access to the msaa buffer.
<imirkin> the scanout is indeed handled separately, by the DRI or whatever winsys layer.
<anarsoul> so where the driver is supposed to resolve to?
<imirkin> the transfer buffer
<anarsoul> ouch
<imirkin> radeonsi definitely supports this ... iris too, most likely, if you want to look at sample impls
<imirkin> with nouveau we largely wimp out ... i.e. don't crash, but also don't work
<imirkin> there are only a handful of piglit tests for this, nothing in CTS iirc
<imirkin> (or maybe we just don't run CTS with a msaa config... hm)
<anarsoul> is it actually used in real-world apps?
<imirkin> almost certainly not
<anarsoul> doing resolve in transfer_map() is going to be *very* expensive for lima
<imirkin> no more expensive than in blit() presumably...
<anarsoul> you don't need to allocate a BO in blit, do you?
<imirkin> i suppose not
<imirkin> end result is the same though
<anarsoul> well, I guess I'll omit it for now :)
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<anarsoul> imirkin: we run deqp with msaa config only for some drivers
<imirkin> i was talking more about nouveau, where we pass all CTS, but probably never ran with the msaa fb
<anarsoul> imirkin: I still wonder if it makes sense to hack winsys to do in-place resolve, at least for tilers. It may be not 100% compliant, but likely good enough for most of cases
<imirkin> anarsoul: yeah, could be. but i'd definitely rather see it done "properly", i.e. by st/mesa or whatever setting up the RB with storage samples = 1
<anarsoul> there're basically 2 options: be compliant and slow, or good enough and fast
<anarsoul> imirkin: yeah, definitely
<imirkin> instead of the driver doing it behind the state tracker's back
Company has quit [Quit: Leaving]
mszyprow has joined #dri-devel
<anarsoul> heh, I wish ARM released the docs for Utgard :)
danvet has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
<HdkR> anarsoul: Everyone wishes for every GPU vendor to release documentation :P
<pq> rasterman, vblank timestamp are MONOTONIC, yes, but they do not need to be strictly <= now, if the driver knows in advance when it will happen. The event can be sent slightly before the actual time.
<pq> different drivers have the vblank interrupt at different times relative to the vblank period, so timestamping that instead makes less sense.
gouchi has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
lemonzest has quit [Quit: WeeChat 3.3]
kevintang_ has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
pcercuei has joined #dri-devel
libv_ is now known as libv
lemonzest has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<MrCooper> vsyrjala: the deadline is defined to be the start of vblank, not sure what a second timestamp for when the interrupt "happened" (was processed?) would buy
camus has joined #dri-devel
mclasen has joined #dri-devel
<emersion> yeah i don't think it'd be very useful
rasterman has joined #dri-devel
kevintang_ has quit [Quit: Connection closed for inactivity]
boistordu has joined #dri-devel
mszyprow has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
DPA has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
DPA- has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
kenjigashu has quit []
kenjigashu has joined #dri-devel
kenjigashu has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
DPA has joined #dri-devel
DPA- has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
kenjigashu has quit []
DPA- has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit []
DPA has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
kenjigashu has quit []
gawin has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit []
Company has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
Haaninjo has joined #dri-devel
kenjigashu has quit []
gawin has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
pushqrdx has joined #dri-devel
LexSfX has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit []
unerlige has quit [Ping timeout: 480 seconds]
mdnavare has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
kenjigashu has quit [Remote host closed the connection]
kenjigashu has joined #dri-devel
kenjigashu has quit []
mszyprow has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
kenjigashu has quit [Remote host closed the connection]
kenjigashu has joined #dri-devel
kenjigashu has quit [Remote host closed the connection]
mattrope has joined #dri-devel
kenjigashu has joined #dri-devel
kenjigashu has quit []
rawoul has quit [Quit: leaving]
<vsyrjala> MrCooper: the deadline is technically hardware specific. the other thing the second timestamp would get you is more accuracy since the kernel knows the actual dotclock used. userspace only knows what it asked which may not be exactly what ends up being used
mszyprow has joined #dri-devel
camus has quit [Remote host closed the connection]
<gawin> how bad is warning in piglit's initialized-texmemory/-fbo test from security?
jn has joined #dri-devel
jn has left #dri-devel [#dri-devel]
glacambre has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
pushqrdx has quit [Remote host closed the connection]
Danct12 has quit [Quit: Quitting]
mszyprow has quit [Ping timeout: 480 seconds]
cphealy has quit [Quit: Leaving]
vyivel has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
glacambre has quit []
<jadahl> vsyrjala: there are two timestamps that are relevant, the presentation time (pixel turned to light) and deadline, anything else i'm not sure how useful it is
vyivel has joined #dri-devel
emersion has joined #dri-devel
<marex> hey, I suspect there is another memleak in etnaviv
<marex> I'm running mesa 21.3.0 and qtwebengine on top of it, and the memory utilization grows, slowly
<marex> is there some recommended way to search for those memleaks in mesa ?
<marex> I suspect it will be some BO which doesn't get free'd or some such
sdutt has joined #dri-devel
cphealy has joined #dri-devel
Danct12 has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
loki_val has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
<robclark> marex: comparing /proc/$pid/maps over time will help show if it is a gem bo leak (mmap against /dev/dri/$devnode) vs something else.. that is first thing I'd check.. not sure if etnaviv supports something like $debugfs/dri/N/gem to dump all the gem buffers (which is more useful if kernel driver supports giving bo's a debug name), but that is the second thing I'd check
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
bgs has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
<marex> robclark: so, massif does show a couple of etna_ functions in the log, now that I have debug symbols
<marex> cat /sys/kernel/debug/dri/0/gem
<marex> Total 0 objects, 0 bytes
<marex> so, lets see
<marex> and with the application running, Total 1049 objects, 244969472 bytes
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
rakko_ has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
oakk has quit [Ping timeout: 480 seconds]
mszyprow has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
rakko_ has quit []
gouchi has quit [Remote host closed the connection]
<marex> robclark: seems the GEM buffer total size is very much constant
<marex> it is fluctuating up and down a bit, but there is no growth
mszyprow_ has joined #dri-devel
macromorgan has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
rawoul has joined #dri-devel
rcf has quit [Quit: WeeChat 3.2.1]
rcf has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<marex> hmmm, maybe there is a leaked BO after all
mszyprow_ has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
nsneck has quit [Remote host closed the connection]