<rah>
HdkR: I've no idea, I don't know why you've introduced the term "display driver"
<alyssa>
HdkR: me_irl oh my gosh
<rah>
so the xorg driver is, in fact, modesetting
<rah>
?
* alyssa
just did a system wide mesa upgrade and wow the difference is noticeable
<alyssa>
I realize i've been a little opaque recently for various reasons but I think you guys will like the next mesa release ;0
<HdkR>
:D
<HdkR>
I have some new hardware arriving today so that image is also my mood
<alyssa>
:D
macc24 has quit [Read error: Connection reset by peer]
macc24 has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
raster has joined #panfrost
cwabbott_ has joined #panfrost
cwabbott has quit [Ping timeout: 272 seconds]
cwabbott_ is now known as cwabbott
<robclark>
alyssa: not sure if you have gone too far down the path of actually trying to make PIPE_SHADER_CAP_INT16 and PIPE_SHADER_CAP_GLSL_16BIT_TEMPS work? I'm starting to look at PIPE_SHADER_CAP_GLSL_16BIT_TEMPS... there are some ir3 RA issues.. and wherever large const arrays get lowered to uniforms is broken.. but in general seems the more useful of the two and not as obviously broken as int16
<alyssa>
robclark: before PIPE_SHADER_CAP_GLSL_16BIT_TEMPS was added I had that MR clear CI so that one should be doable at least
<alyssa>
had some misc fails to fix but nothing horrifying
* alyssa
eyes
<robclark>
yeah, I haven't found anything pre-ir3 that is *obviously* broken, but it does seem to defeat some front-end opts and end up being worse as a result
<alyssa>
:|
<robclark>
look at dEQP-GLES3.functional.shaders.large_constant_arrays.indexing.float_16_fragment for ex..
<alyssa>
getting fp16 flipped on master was my next todo after this code review stack so I guess we can debug this together :p
<alyssa>
"wherever large const arrays get lowered to uniforms is broken.." We don't do this in panfrost yet
<alyssa>
We probably should but we don't yet
<robclark>
ok, no worries.. I'll keep digging in, just wanted to make sure I wasn't stepping on feet
<robclark>
it seems like it happens before glsl_to_nir? I didn't look too far
* alyssa
reboots
<alyssa>
my deqp is built wayland only but gnome-wayland breaks terribly on my external monitor so I have to use in laptop mode, but disconnecting the monitor from X11 ends up hanging somewhere down the stack
<alyssa>
the joys of dogfood
<alyssa>
okay, let's dig in
<alyssa>
robclark: huh, right, it is getting lowered
<alyssa>
Never saw that before :o
* robclark
built deqp for surfaceless to match CI setup
<alyssa>
wise..
<robclark>
probably should compare shader-db results too, to make sure there aren't other opt regressions
<alyssa>
FP16 as a whole is a regression on a lot of shaders for us rn due to conversions :|
<robclark>
(but since not lowering large const arrays is triggering ir3 bug, I'm debugging that first)
<robclark>
we do have to do conversion-folding in backend to avoid too-many-conversions
<chrisf>
robclark, are you happy with surfaceless, or would you use gbm platform if i revived it properly?
<robclark>
hmm, I guess no strong opinions.. I just wanted to duplicate the setup we have in CI so I could reproduce fails seen there
<alyssa>
robclark: okay, I can repro the regression with that test
<chrisf>
i got chadv's old patch working again well enough that i can run against the mali blob as well etc
<alyssa>
the regressed one still runs fine but meh
<robclark>
I think the deqp-egl tests don't work with surfaceless tho.. not sure if that is better w/ gbm
<alyssa>
I'm curious why ir3 ra fails on that?
nlhowell has quit [Ping timeout: 258 seconds]
<alyssa>
lots of instructions but register pressure isn't bad
<robclark>
arrays in regs.. and having to deal with both merged and split reg file
<robclark>
(ie. half-regs can conflict with full regs.. or not)
<chrisf>
robclark, deqp-egl is still pretty busted with it currently but that might be fixable
<alyssa>
also unclear - when I expose an ES2 context, the glmark shaders run but nothing else in shader-db; when I expose ES3, the ES3 shaders run but the glmark ones don't anymore ;-;
<alyssa>
also, *none* of the ES3 shaders are mediump (?)
<alyssa>
er, maybe it's only hitting desktop ones? it's not even compiling manhattan
<robclark>
alyssa: shader-db doesn't have the best mediump coverage, I suppose.. I have some .shader_tests from gfxbench (manhattan, etc) which are gles3.*
<alyssa>
"requires GLSL ES 300" it's an ES3 context what do you want from me shader-db
<robclark>
chrisf: I guess I wouldn't have even tried running deqp-egl, other than trying to repro an android cts issue.. which actually seems more like a container issue when I dug into it (at some point attempting to open drm dev file starts returning -EPERM)
<alyssa>
Merge Request !5858 was merged
<alyssa>
Woohoo!
<alyssa>
If you grab the latest mesa master, Panfrost now ships GLES3 out-of-the-box on Mali T760 through Mali T860
<alyssa>
Also, Chromium works now (with full hardware acceleration, including WebGL although it's not the most performant thing yet)
<robclark>
nice
<robclark>
ok, ir3 ra vs 16b fixed.. turned out I just had to delete a bit more code.. let's see what is going on w/ the const lowering now
<robclark>
oh, hmm, I wonder if I didn't see that because of gl glsl version exposed?
<alyssa>
Perhaps, panfrost master is ES3.0 but GL2.1
<alyssa>
(very close to GL3.1 but not quite there yet)
raster has quit [Quit: Gettin' stinky!]
TheMojoMan has joined #panfrost
TheMojoMan has quit [Ping timeout: 240 seconds]
davidlt has quit [Ping timeout: 240 seconds]
<daniels>
rah: yep, -modesetting
<daniels>
HdkR: a shame indeed; haven't seen any commercially-available silicon with Mali-DP or Mali-V for that matter
rah has left #panfrost [#panfrost]
<daniels>
alyssa: ES3! 🎉
<alyssa>
🎉🎉
<HdkR>
:party popper:
<daniels>
great work you, bbrezillon, HdkR, icecream95, Lyude, shadeslayer, and all others :D
<alyssa>
\o/
<alyssa>
and tomeu
<alyssa>
<daniels> how did I forget tomeu?
<alyssa>
=P
<daniels>
err, I did start with him in there, but lost him in diplomatic alphabetising :(
<alyssa>
this is why I like having a name that starts with A (:
<urjaman>
:D
<alyssa>
urjaman: at any rate your CAD program should be working on master now :)
macc24 has quit [Quit: slep]
<urjaman>
yeah i'm about to test soon(TM)
icecream95 has joined #panfrost
<alyssa>
urjaman: and if it isn't, wasn't me.
<urjaman>
i have done a quick test and it works*, but i found more stuff to fix lol
<urjaman>
the far zoomed out view (that the trace was of) looks fine, and the rendering seems fine and snappy enough etc... but as you zoom in, circles are occasionally triangles??
<urjaman>
I also tested eeschema, the schematic editing component of kicad, results are very similar, it works but circular nodes are triangles on some zoom levels
<urjaman>
also I don't want to sound ungrateful, actually hardware accelerated kicad on this little ARM laptop is wayyy coool :D
<alyssa>
woof
<alyssa>
urjaman: can't reproduce the issue on t860 from that trace
<alyssa>
(i.e. still circles for me?)
<alyssa>
maybe a t760 difference somewhere down the stack
<icecream95>
I can reproduce on t760
<alyssa>
it's a good thing we don't support t7-- shoot ;p
<urjaman>
(T760 that is) but anyways in addition to the obvious circles, there's something funky with the pcb font ... some of the letters are just boxes
<urjaman>
which kinda feels like the same problem, a shape with lots of points is rendered as just 3 or 4 points
<icecream95>
some of the mali_shader_meta structs don't have MALI_DEPTH_CLIP_*, but the trace doesn't even use DEPTH_CLAMP...
megi has quit [Quit: WeeChat 2.8]
<alyssa>
clipping, culling, and clamping are all different..
<alyssa>
and at least 1 is probably broken for us :d
<alyssa>
I guess !clipping => clamping though
<icecream95>
I also see things like warn: expected work_count = 1, claimed 4 and XXX: expected helpers 1 but got 0
<alyssa>
icecream95: that's me being really lazy with wallpapering
<alyssa>
/reloads
<alyssa>
the work count is, I mean
<alyssa>
the helpers is intentional since we know for reloads there's no mipmapping to worry about so we can disable them as a micro opt
<alyssa>
but pandecode doesn't know that
<alyssa>
urjaman: the vertex shader is intense.
megi has joined #panfrost
<alyssa>
`brx.cond.always +45` seems suspect
<alyssa>
oh, right, if-else sequences, sure
<icecream95>
alyssa: So disabling clipping is just another micro opt for the blit shader?
icecream95 has quit [*.net *.split]
milkii has quit [*.net *.split]
tgall_foo has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
Green has quit [*.net *.split]
narmstrong has quit [*.net *.split]
mearon has quit [*.net *.split]
alyssa has quit [*.net *.split]
<urjaman>
geeze, not the best timing for a netsplit