<alyssa>
Which shoves the FPS on the on-screen HUD
<HdkR>
Neat, even a wacky format like GL_R11F_G11F_B10F goes through the same tiler blit copy path
<alyssa>
HdkR: For read or for write?
<HdkR>
Same format on either side
<HdkR>
These API provided copies are sort of strict :P
<alyssa>
HdkR: Out of curiosuity, um,
<alyssa>
What's the foramt code for that?
<alyssa>
(Just grep for "format =" lines, although maybe if your panwrap is _that_ old)
<HdkR>
format = 0x88888119,
<alyssa>
That's the framebuffer fmt, and the texture?
<alyssa>
I guess you don't have the texture fmt convenient if you're using old panwrap
<alyssa>
HdkR: Also, the value of "unk1" right above the format = ..?
<HdkR>
.unk1 = 0x88000000,
<alyssa>
Thank you
<HdkR>
Yea, can't see the texture format in this one it looks like
<alyssa>
HdkR: I mean, it's there, but it's splatted across a bunch of fields as hex and it's inconvenient to extract
<alyssa>
This would not be a problem if you switched to recent panwrap/pandecode, ahem :p
<HdkR>
:P
<alyssa>
Decoded: not AFBC, not MSAA, 4 components, swizzle XYZ0
<alyssa>
I don't know the meanings of the other bits
<HdkR>
Interestingly GL_RGB10_A2UI seems to change the blit shader a bit
<HdkR>
Glues a nop clause to the front
<hanetzer>
robher: does your panfrost-5.0* branch have the removal of panfrost ip stuff in it?
<robher>
hanetzer: it doesn't, but it can.
<hanetzer>
k, because my rework of the tracepoints takes that into account :P
<robher>
hanetzer: now it does.
<hanetzer>
wewt. if'n its aight with you I may just shove my patches your way :P
* hanetzer
is quite glad some more capable people are working on the new kmod other than himself
Elpaulo has joined #panfrost
Elpaulo1 has joined #panfrost
Elpaulo has quit [Ping timeout: 244 seconds]
Elpaulo1 has quit [Ping timeout: 244 seconds]
Elpaulo has joined #panfrost
Elpaulo1 has joined #panfrost
Elpaulo has quit [Ping timeout: 246 seconds]
Elpaulo1 has quit [Ping timeout: 240 seconds]
Elpaulo has joined #panfrost
Elpaulo1 has joined #panfrost
Elpaulo has quit [Ping timeout: 244 seconds]
Elpaulo has joined #panfrost
Elpaulo1 has quit [Ping timeout: 245 seconds]
Elpaulo1 has joined #panfrost
Elpaulo has quit [Ping timeout: 240 seconds]
Elpaulo has joined #panfrost
Elpaulo1 has quit [Ping timeout: 245 seconds]
Elpaulo has quit [Ping timeout: 244 seconds]
<alyssa>
Oh, that's really cute -- it looks like transform feedback requires nothing new in the cmdstream
<alyssa>
Which makes sense, since varyings are already written back to main memory where the driver tells it to go :)
<HdkR>
:D
<HdkR>
Sad thing is, the only thing that are going to use those anymore are Direct3D games :P
<HdkR>
and DXVK
<alyssa>
Good to know
<alyssa>
There, I found the bit for PRIMITIVE_RESTART_FIXED_INDEX
<alyssa>
That counts for something
shenghaoyang has joined #panfrost
* alyssa
wonders why neverball is never working again
<alyssa>
Apparently it's getting a stack overflow... not sure how to debug this
<alyssa>
Ohhh uh
* alyssa
forgot how broken primconvert is
_whitelogger has joined #panfrost
stikonas has joined #panfrost
<Lyude>
read up on graph coloring and linear scanning for register allocation
<Lyude>
Tried to read the SSA docs but it very much seems like there is some prerequisite knowledge I need to learn to understand that paper even slightly :s
<Lyude>
( cwabbott?)
<cwabbott>
Lyude: what exactly confuses you about it?
<Lyude>
I have no understanding of what SSA is :p
<Lyude>
it seems like it's an overcomplicated way of saying "hey here's an IR where we've taken every variable assignment and represented them uniquely"
<Lyude>
Note: I had no internet
<cwabbott>
oh, well, in that case... yeah, you need to read up on SSA first
<Lyude>
so I'm probably about to find all of the answers to this on Google in a moment
<cwabbott>
there are, well, tons of great things about SSA, but if I had to choose one thing, it's that it makes forward dataflow problems like constant folding really really easy
<cwabbott>
also, it's kinda like functional programming, in that if two operations take the same sources, then they always produce the same value
<Lyude>
(also hi from London)
<cwabbott>
:)
raster has joined #panfrost
<davidlt>
Static single assignment ?
<davidlt>
I think, each compiler have SSA before doing anything
<HdkR>
SSA isn't the only form of IR
<davidlt>
yes, it's not, but you always have it
<davidlt>
well, GCC and LLVM definitely has it
<davidlt>
also all compiler courses at university incl. SSA
<HdkR>
The only compilers that matter </s>
raster has quit [Remote host closed the connection]
<tomeu>
alyssa, robher: glmark was crashing because the DRM backend didn't have implemented free_slab
<tomeu>
have pushed implementations for the missing callbacks
<tomeu>
there's some artifacts in weston which look like if FBOs were presented before rendering is complete, so I'm going to debug the fences stuff
<tomeu>
otherwise, glmark2 runs quite well on KMS, until the blue cat
<tomeu>
alyssa: I think I'm going to submit soon my DRM backend to mainline
<tomeu>
and once you are happy with how it works, I will start cleaning stuff up starting with removing the driver abstraction
<Lyude>
davidlt: take note of the university courses I have taken:
<Lyude>
:p
<Lyude>
cwabbott: btw before I go offline, does mesa have any non-llvm helpers for generating SSA?
<Lyude>
(also this is very fun reading so far :)
<cwabbott>
Lyude: NIR is SSA-based, that was one of the main reasons for creating it
<Lyude>
sweet
<Lyude>
ok yeah now things are starting to click! :D
raster has joined #panfrost
raster has quit [Ping timeout: 255 seconds]
<cwabbott>
Lyude: nice!
raster has joined #panfrost
pH5 has joined #panfrost
BenG83 has joined #panfrost
<daniels>
Lyude: *waves from north London*
<daniels>
cwabbott: did your initial submission of NIR with the world's longest cover letter cover some of the SSA basics as well, or am I misremembering?
<daniels>
tomeu: weird, rockchip-drm should be fencing on any reservation object you place on the dmabuf
<cwabbott>
daniels: I don't remember, but I don't think so
<daniels>
cwabbott: fair enough
<tomeu>
daniels: what I'm doing right now is placing reservation objects on the BOs :)
<daniels>
GBM BOs are always pixel buffers, but non-GBM BOs can be anything, e.g. pipeline descriptors, compiled shader programs, UBO data, etc etc
<hanetzer>
gpu texture or shader or sommat when talking in user terms, eh?
<daniels>
most of the places you see it exposed outside drivers, it's either backing data for a texture (one or more miplevels of) or a render target / FBO, yeah
<daniels>
inside a driver, it can be those, or other user buffer data (e.g. vertex/attrib data), or compiled shader programs, or ... anything really
<tomeu>
if this trend of stealing code from v3d continues, we may better asking anholt to let us merge our code into v3d itself
<hanetzer>
hehe
<hanetzer>
is it even similar enough to do so?
<tomeu>
you mean similar enough so that code can be copied pretty much as-is?
<hanetzer>
heh.
<hanetzer>
well, would require some funny stuff wrt device probe at the very least
paulk-leonov has quit [Ping timeout: 250 seconds]
<tomeu>
yeah, wasn't serious
paulk-leonov has joined #panfrost
<tomeu>
crap, fences are set, and even if they get waited on and time out (I'm not signaling them jet), I still get rendering artifacts
<raster>
you get things rendering...
<raster>
lucky you
<raster>
:)
paulk-leonov has quit [Max SendQ exceeded]
<tomeu>
heh, in a bit everything will be upstream and distros will start packaging it :p
<hanetzer>
heh. well, gotta get the kmod nice too :P
paulk-leonov has joined #panfrost
<tomeu>
kmod? what for?
<hanetzer>
for upstream :P
<raster>
i'd like to get it working earlier
<raster>
i did have a prevois kbase+panfrost tree working
<hanetzer>
I realize that we can use mali_kbase and all but ideally it would be a sane, in-tree kmod
<raster>
but my new "track mainline mesa" + kbase... not so good
<raster>
hmm
<tomeu>
hanetzer: well, but this would be a normal in-tree driver, as rockchip-drm is, for example
paulk-leonov has quit [Max SendQ exceeded]
<raster>
seems it's a mesa issue
<raster>
not kbase
<hanetzer>
tomeu: I think we're not talking about the same thing. I mean panfrost.ko, not mali_kbase
<raster>
hanetzer: eventually that probably is the path it'll go via
<raster>
but right now kbase is what is the "stable working" kernel bit
<raster>
and the userspace parts need work still :)
<hanetzer>
yeah.
<tomeu>
hanetzer: I'm also talking about panfrost.ko, but yeah, I'm not sure what we are talking about
paulk-leonov has joined #panfrost
<raster>
it's all in transition so ... i'm going to, for now, stick to the kernel bit that is not transitioning anywhere... :)
<raster>
now... why the hell does mesa not want to load panfrost... hmmm...
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
<tomeu>
any ideas on what's the cause for these artifacts? people.collabora.co.uk/~tomeu/2019-02-27-144035.webm
<tomeu>
doesn't seem to be presenting before rendering has finished
<tomeu>
robher: I'm wondering if it isn't a caching issue
<robher>
tomeu: don't we have a cache flush flag set at the start and end of every job?
<daniels>
tomeu: weird that it happens at (0,0) in GL origin space ...
<tomeu>
daniels: we flip it iirc, so it may be the end
<daniels>
tomeu: right, but even then it seems weird given that the end tile would presumably be x==width, not x==0
<tomeu>
robher: yep:
<tomeu>
cfg = JS_CONFIG_THREAD_PRI(8) |
<tomeu>
JS_CONFIG_START_FLUSH_CLEAN_INVALIDATE |
<tomeu>
JS_CONFIG_END_FLUSH_CLEAN_INVALIDATE;
<daniels>
which makes me think it's probably more about the first tile
tgall_foo has quit [Read error: Connection reset by peer]
paulk-leonov has quit [Max SendQ exceeded]
<tomeu>
sometimes it's not the last one, btw
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
tgall_foo has joined #panfrost
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
<tomeu>
robher: have pushed BO implicit fences
paulk-leonov has joined #panfrost
<tomeu>
guess next I will wire up out fences to userspace, which I guess it's needed for glReadPixels and so
<robher>
tomeu: another thing to check would be whether we get new mappings or not while this is happening. If we're not faulting, then it would have to mean we're drawing to an old mapping briefly.
paulk-leonov has quit [Max SendQ exceeded]
<robher>
one of the tlb syncs in kbase is just wait some number of gpu cycles and I haven't implemented that.
paulk-leonov has joined #panfrost
<tomeu>
ah, will try to find that out
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
Elpaulo has joined #panfrost
Elpaulo1 has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
Elpaulo has quit [Ping timeout: 268 seconds]
Elpaulo1 is now known as Elpaulo
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
<tomeu>
robher: if you refer to kbase_wait_write_flush, there's a comment saying that it only applies to BASE_HW_ISSUE_6367, which exists in some t760s
<tomeu>
but in that case, and because that area has always the same contents, wonder why it would be black
<tomeu>
I would epxect it to have the old contents, which would match what is expected
paulk-leonov has quit [Max SendQ exceeded]
<robher>
tomeu: Ah, that's probably why I ignored that for now.
<robher>
tomeu: A TLB issue wouldn't be my first guess, but was just something I had in my head.
<tomeu>
that's why I was wondering about some memattr causing 0s being read from a cache that isn't populated
paulk-leonov has joined #panfrost
<robher>
As black is all 0s, seems more like a cleared buffer and drawing hasn't finished.
<tomeu>
I can change the clear color in weston's gl-renderer
<tomeu>
but I checked and the implicit fencing seemed to be working
<tomeu>
but it's true that it stops happening once I put enough printks :)
<tomeu>
so it looks like a race indeed
<tomeu>
another observation: if there's windows being rendered, the black tiles cover a greater surface
paulk-leonov has quit [Max SendQ exceeded]
<robher>
tomeu: yeah, memattrs could be an issue.
<tomeu>
daniels: I don't see any clears in gl-renderer
paulk-leonov has joined #panfrost
paulk-leonov has quit [Max SendQ exceeded]
paulk-leonov has joined #panfrost
<tomeu>
robher: forced panfrost to always clear to a given color, and I'm still seeing black
<tomeu>
ah, I remember the memattrs in the dump being different to what we program
<tomeu>
didn't seem to make any different at that point though
<robher>
I was thinking more that the cpu cleared pages rather than the gpu. But probably shmem pages don't get cleared.
<daniels>
tomeu: right, we always have a background so there is guaranteed to be at least one opaque view covering every on-screen quad
<tomeu>
robher: I don't think any more that it's a problem with how the display hw is reading the buffer, because I have managed to reproduce such that I see tiles that are half-rendered
<tomeu>
so they aren't all black
<tomeu>
so probably we are starting to render on a buffer that is being displayed?
<daniels>
tomeu: with buffer_age we only repaint damaged regions, and without buffer_age we just wait until we have a complete scene before we paint; either way we have no reason to clear
<tomeu>
s/displayed/scanned out
<tomeu>
wonder who has to wait for scan out to finish before rendering on top of a buffer
<raster>
daniels: don't get fooled by thinking the black is due to a clear :)
<raster>
this isn't any special info 0 it's generic from my past ...
<raster>
some gpu's do tiled rendering (funny that) ... ye s- obvious
<raster>
BUT
<raster>
it depends on how tiles are managed
<raster>
to do partial rendering some gpu's have to EXPLICITLY dma in the buffer content
<raster>
THEN render
<raster>
to do partial updates you have to dma in the regions you won't render
<raster>
then draw the region you will
<raster>
then flush the rendered tile out
<raster>
the black could simply be just the default tile content on beginning of a tile render
<daniels>
yeah, exactly - hence my WIP implementation of EGL_KHR_partial_update for both Mesa & Weston :)
<raster>
*the tile memory could be able to self-zero or to constant values
<raster>
it may be implicit in starting the tile up
<raster>
so thus... that black could be an unfilled tile having been flushed back to ram?
<raster>
daniels: oh.. that'd be awesome if you can land that...
<raster>
daniels: also it's hellishly useful for the swapbuffer as now u have a region list to pass to the xserver for damage regions or to the wl compositor :)
<daniels>
raster: ah, we already have EGL_KHR_swap_buffers_with_damage in both Mesa & Weston, and they DTRT for Wayland clients ;)
<daniels>
*:)
<daniels>
but yeah, having partial_update to avoid unnecessary tile loads would be awesome
<raster>
when did this land?
<raster>
damn
<raster>
i need to fix out extn string handling
<raster>
we look for EGL_EXT_swap_buffers_with_damage + eglSwapBuffersWithDamage() proc addr
<daniels>
raster: yeah exactly - WIP for partial_update so we can avoid tile loads during rendering; swap_buffers_with_damage only solves the sampling side :)
<raster>
yup yup. never mind. i was being silly
<raster>
though in theory if the rendering si deferred ... and no cmds are actually issues until the swap ... the info is at the end of the pipeline and can be inferred back to the start :)
<raster>
tomeu: that's biazarre
<raster>
the patterns around the bottom-left of the wallpaper dont make a lot of sense...
<raster>
the glmark client also is just... weird
<raster>
why would rockchip_dri not load panfrost... hmmm
<urjaman>
(i thought that was replaced with kmsro?)
<urjaman>
i dunno tho how it works these days, i havent dabbled in months
<raster>
well mesa is loading rockchip .. not kmsro
<raster>
mesa is installs a rockchip_dri.so... which is then insists on using...
<raster>
do i need to mess with my devicetree?
<tomeu>
raster: I think it could be a good idea to start anew
<tomeu>
you seem to have some old cruft installed that is getting in the way
<raster>
i rm -rf'd all of my panfrost install :)
<raster>
as i put it in /opt/panfrost ...
<raster>
that was easy :)
<tomeu>
then I don't get why mesa is installing rockchip_dri.so
<alyssa>
raster: Yeah, midgard follows the "explicitly dma back buffer content, then render" model... except there's not dma, it's just a fullscreen quad we have to draw with a simple texture-passthrough shader... and there's no default colour, it's just whatever the clear colour is (we _always_ have to set a clear colour)
<alyssa>
tomeu: kmsro installs to rockchip/meson/etc... all the files are identical... rockchip_dri.so is still correct
<alyssa>
tomeu: Actually, what that bug really looks like it might be is a race condition between the vertex/tiler job and the fragment job
<raster>
alyssa: actually i think my experience comes form any years ago was not a mali gpu.. it was something else that also did tiled rendering :)
<alyssa>
Notice that in nondrm, we have to set a DATA dependency between the two
<tomeu>
that sounds promising
<raster>
so should rockchip also load/open panfrost_dri.so ?
<raster>
these days?
<alyssa>
tomeu: The symptom for that bug in early days was "random tiles were missing and just black instead"
<alyssa>
raster: ...It should?
<alyssa>
Do you have the nondrm overlay?
<raster>
i'm asking if it should
<raster>
just mesa git master
<raster>
i hadn't moved on from the panfrost git repo until yesterday
<raster>
i'm now updating to mesa git master and now... it stopped working :(
<alyssa>
raster: Okay, so, for upstream mesa (a.k.a panfrost from past-February), you need some extra out-of-tree glue to talk to mali_kbase
<raster>
ooooh
<raster>
so what is meant to work with what these days?
<alyssa>
Since we can't upstream those bits for obvious reasons
<raster>
too mcuh stuff changing to keep up with! :)
<alyssa>
raster: Would you rather we make less progress? ;P
<alyssa>
raster: Atm, it should be kbase. At least, I'm using kbase
<raster>
ok
<raster>
got it
<alyssa>
Same kbase version as you had working before
* alyssa
school
<raster>
alyssa: tnx
<raster>
i see docs changed :)
shenghaoyang has quit [Remote host closed the connection]
<raster>
yay!
<raster>
renders again
<raster>
tho it seems buffer age is back to being supported which results in partial updates being triggered in efl
<raster>
and that emans only rects around the render area are rendered and everythign else black
<raster>
woot
raster has quit [Remote host closed the connection]
pH5 has quit [Quit: bye]
<HdkR>
TIL that the Playstation 1 used a linked list for draw commands on its GTE
pH5 has joined #panfrost
Elpaulo has quit [Quit: Elpaulo]
<HdkR>
Oh
<HdkR>
Robert got interviewed by Charbax
* HdkR
remembers there are like three or four of them in here
<HdkR>
Foss*
<HdkR>
I presume that is Charbax anyway? Hard to tell from behind
<HdkR>
Guess not, looks like he is currently at MWC :P
<alyssa>
HdkR: I'm only aware of like 3 Roberts in here
<HdkR>
A whole island of Roberts
<urjaman>
hmm what is the current state of things on t760?
<alyssa>
urjaman: Theoretically feature par with T860
<alyssa>
May be broken at any given moment
<alyssa>
robertfoss: BTW, any chance your talk slides/video are posted?
<alyssa>
I'm kinda curious
<urjaman>
anything that i need to to differently (from the instructions in the link above)?
<alyssa>
urjaman: Maybe add a compatible line in the mali_kbase
<alyssa>
I can look this evening
<urjaman>
because i just got flash strobed by kmscube and got a series of "error detected from slot 1, job status 0x00000058 (DATA_INVALID_FAULT)" in dmesg
<alyssa>
robertfoss: Although I guess half of it is posted as photos on twitter :p
<alyssa>
urjaman: Grumble, guess I regressed something. Will look later
<HdkR>
The interview would be nice to see as well :P