<tomeu>
alyssa: if Google was able to get Chromium working well on Chromebooks with the mali blob, I'm confident we'll be as well :)
<tomeu>
/* TODO: Check viewport or something */
<tomeu>
bool flip_y = panfrost_is_scanout(ctx);
<tomeu>
wonder what we should do with that TODO
BenG83 has quit [Ping timeout: 258 seconds]
<tomeu>
alyssa: I think that won't work, because client buffers (SHARED) need to be either rendered to flipped and sampled from unflipped, or the other way around
<tomeu>
but they will look upside down if are either flipped or unflipped
<tomeu>
so I think that SCANOUT needs to be flipped both when rendering and when sampling from it, and client buffers need to be rendered to flipped and sampled from unflipped
danvet has quit [Ping timeout: 248 seconds]
pH5 has quit [Quit: bye]
mearon has quit [Ping timeout: 276 seconds]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
mearon has joined #panfrost
<tomeu>
alyssa: looks like we have regressed lately, these tests started to reliably fail on at least rk3288: dEQP-GLES2.functional.shaders.functions.qualifiers.inout_lowp_int_vertex and dEQP-GLES2.functional.shaders.operator.binary_operator.mul.lowp_ivec4_fragment
raster has joined #panfrost
<shadeslayer>
tomeu: alyssa so I looked a bit more at how v3d handles deleting a context and one of the first things it does is flush all the jobs
<shadeslayer>
panfrost_destroy doesn't seem to be doing anything similar
<shadeslayer>
I'm also not sure why the flush doesn't iterate over all the jobs
<tomeu>
shadeslayer: I think not everything that should be in panfrost_job is there yet
<shadeslayer>
right
cwabbott has quit [Ping timeout: 248 seconds]
cwabbott has joined #panfrost
gcl has quit [Ping timeout: 258 seconds]
gcl has joined #panfrost
<shadeslayer>
tomeu: I think I need to implement panfrost_job_submit first
<shadeslayer>
then implement flushing and then call panfrost_flush on context deletion
<shadeslayer>
then we can probably get rid of that todo along with my patch from earlier
<shadeslayer>
and panfrost_job_submit looks complicated to implement xD
<shadeslayer>
Is there a document that describes how jobs are supposed to be submitted ?
<shadeslayer>
alyssa: ^^
<Lyude>
HdkR: btw
<Lyude>
did you hear what karol managed to fix? :)
<alyssa>
shadeslayer: Documentation? What's that :(
<shadeslayer>
:(
<alyssa>
shadeslayer: Documentation seems to consist of comments and IRC logs, alas
<alyssa>
The weirder parts of the hw are pretty well-commented, I hope
<alyssa>
E.g. pan_blending.c
<shadeslayer>
This is about the CL
<shadeslayer>
I was just reading what v3d and vc4 do
<alyssa>
First of all, we don't have a real CL, though we pretend we do to make our code look like other drivers
<alyssa>
Midgard is based on descriptors, rather than a command stream,
<alyssa>
Lots of pointers all the way down. C structs, basically.
<alyssa>
Reminds me of a functional programming language. Rather than imperatively setting the hardware state (command lists), we just give it the descriptor of how it should be configured.
<alyssa>
include/panfrost-job.h is all such known descriptors
<shadeslayer>
oh wow
<shadeslayer>
alyssa: any pointers on what panfrost_job_submit would entail?
<shadeslayer>
I think I need this so that we can flush all jobs during context deletion
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #panfrost
raster has quit [Remote host closed the connection]
<alyssa>
shadeslayer: Sure, take a peak at the function panfrost_submit_frame in pan_context.c
<alyssa>
Ideally, that would be abstracted to work on jobs rather than pan_context directly, and then everything should fall into place naturally (just rename the function, heh)
<shadeslayer>
ack :)
<shadeslayer>
I'll spend some time on it tomorrow I suppose
<alyssa>
shadeslayer: It's been on my own todo list for a while. If there's a particular part you do/don't want to work on, tell me :)
<shadeslayer>
alyssa: It's more like, I'm not entirely sure how all of this works and I'm kinda working with incomplete knowledge
<shadeslayer>
and that's what frustrating
<alyssa>
shadeslayer: Honestly? Same here, also frustrated. I wrote the code but that doesn't mean I get it either :(
<shadeslayer>
alyssa: well, I'm also getting familar with how gallium works, so it's a pretty steep learning curve :)
<shadeslayer>
I learn by doing, which is why I was thinking of picking this up
<alyssa>
shadeslayer: I remember the days, yeah..
<shadeslayer>
:D
<alyssa>
shadeslayer: You'll get your wings, I promise :)
<shadeslayer>
hope so :)
<alyssa>
Took me a few months of working with Gallium for it to 'click'
<shadeslayer>
aha :)
<alyssa>
Doesn't help that Gallium is about as documented as Panfrost ...
<alyssa>
OA
<alyssa>
tomeu: Hm. Those are both working reliably here on RK3399
<shadeslayer>
alyssa: I mean, I can navigate the code, but then I get stuck on reading things like what a job is in the context of a framebuffer
<alyssa>
shadeslayer: That's my fault for being lazy with language, sorry :(
<shadeslayer>
alyssa: nah, I'm just new to this ;)
<alyssa>
'Job' in the context of the hardware is basically "a bunch of descriptors that do something"
<alyssa>
'Job' in the context of panfrost_job follows v3d usage, basically 'all the state corresponding to a frame of a single framebuffer'
<shadeslayer>
I see, would be useful to make a dictionary :D
<alyssa>
Tell me about it >_<
<shadeslayer>
haha
<alyssa>
tomeu: Obviously it's the int series that would have regressed them, but... huh. Does this mean we're hitting architectural differences across Midgard gens?
pH5 has joined #panfrost
<tomeu>
alyssa: could be, our kevins aren't feeling well today
<tomeu>
alyssa: tomorrow I will check on my nanopc
stikonas has joined #panfrost
yann has joined #panfrost
<alyssa>
tomeu: Hope Kevin gets better soon :-(
<alyssa>
Common cold, or..?
pH5 has quit [Quit: -_-]
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #panfrost
<HdkR>
Lyude: I did not hear what Karol managed to fix
<Lyude>
HdkR: i'll give you a hint
<Lyude>
it starts with an r, and ends with an m
<HdkR>
ah, rocm
<Lyude>
no lol
<Lyude>
runpm
<HdkR>
:P
<Lyude>
for pascal
<HdkR>
ooo, fancy
<Lyude>
yep! laptops aren't broken af now, or will be unbroken very soon
<Lyude>
still some secboot issues to figure out, but they seem to be fully unrelated to the runtime PM issues (and I'm pretty sure we should be able to fix them)
<HdkR>
Does it fix the MX150 as well then?
<HdkR>
So many devices shipping with that low end thing
<Lyude>
HdkR: if it's not pascal probably not
<HdkR>
It is
<Lyude>
ah
<Lyude>
then it should, if not let me know
<HdkR>
I really don't even want to try installing the driver for it. Would just burn my battery :P
<HdkR>
Dumb thing has no video decoders so you run in to the issue that the expectation is apps would use the Intel video decoder
<Lyude>
really? yikes
<Lyude>
it's been a while since i've heard of a GPU with no video decoders, but maybe I just don't look closely enough
<HdkR>
Works fine under Windows obviously. Linux there issues attempting to do that :D
<HdkR>
Yea, low end stuff from Nvidia doesn't have them, so this latest generation there is MX110, MX130, MX150 all without
stikonas has quit [Remote host closed the connection]