alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
vstehle has quit [Ping timeout: 240 seconds]
NeuroScr has quit [Quit: NeuroScr]
megi has quit [Ping timeout: 240 seconds]
NeuroScr has joined #panfrost
_whitelogger has joined #panfrost
vstehle has joined #panfrost
davidlt has joined #panfrost
yann|work has quit [Ping timeout: 240 seconds]
rellla has quit [Remote host closed the connection]
rellla has joined #panfrost
rellla has quit [Remote host closed the connection]
rellla has joined #panfrost
pH5 has joined #panfrost
NeuroScr has quit [Quit: NeuroScr]
davidlt has quit [Remote host closed the connection]
<tomeu> narmstrong: btw, do you have a branch with the lava changes?
<narmstrong> tomeu: yes, I need to rebase on top on your work and cleanup
<narmstrong> DEVICE_TREES needs "" to the script
<narmstrong> boot-method must be specified, like eventual tags (we have a dedicated VIM2 for panfrost)
<tomeu> narmstrong: ok, I'm going to take it into my branch
<narmstrong> I added the device types to the build:arm6 4/build:armhf jobs
<tomeu> will squash it all
<tomeu> I'm including the panfrost CI into mesa's main one
<narmstrong> tomeu: nice !
davidlt has joined #panfrost
<tomeu> narmstrong: could you add to your runner a /root/.config/lqa.yaml file with the equivalent contents to that of lavacli?
<narmstrong> tomeu: yes
<tomeu> thanks
<narmstrong> tomeu: done, but while testing locally, seems lqa have issuew with python3.6 :-/
<tomeu> argh
<tomeu> narmstrong: lqa from debian testing?
<narmstrong> tomeu: I took it from git and pip install
<narmstrong> tomeu: lqa from apt works fine
<tomeu> phew
<narmstrong> should work in the runner now :-p
<tomeu> thanks!
davidlt has quit [Ping timeout: 240 seconds]
jernej has quit [Remote host closed the connection]
<shadeslayer> just want a second opinion to make sure it looks correct
jernej has joined #panfrost
<bbrezillon> shadeslayer: drm_gem_label_ioctl() should check a few things before passing the request to the driver
<shadeslayer> bbrezillon: oh? like the arg len/name?
<bbrezillon> like 'if (args->len > 0 && !args->name) return -EINVAL;'
<shadeslayer> right, I do that check in drm_gem_label
<bbrezillon> and the strndup_user() should be done in there too
<shadeslayer> I see
<bbrezillon> I'm still not sure why driver would need to overload the default function though
<shadeslayer> bbrezillon: apparently not every driver uses gem
<bbrezillon> then the ioctl name is wrong
<shadeslayer> yeah, I just noticed, should be drm_label_ioctl ?
<shadeslayer> or label_bo
<bbrezillon> and I'm not even sure we should have a common ioctl for GEM and TTM
<bbrezillon> actually, I don't even know how TTM buffers are referenced (is there a 32-bit handle like with GEM?)
<bbrezillon> shadeslayer: looks like it's still a 32-bit handle, so just rename the ioctl function
<bbrezillon> that should be enough
<shadeslayer> ack
<bbrezillon> I mean, the first part of the second condition
<shadeslayer> yeah, it's useless
<shadeslayer> oh wait no?
<shadeslayer> bbrezillon: that's for clearing a label
<shadeslayer> so maybe that -EINVAL needs fixing
<bbrezillon> yes, but the first part of the condition is always false
<shadeslayer> bbrezillon: with both of those checks, yes
<bbrezillon> because of the test you do earlier in the function (which I think you want to get rid of)
<shadeslayer> so the first check needs fixing to take clearing into account
<shadeslayer> yep, good catch
<bbrezillon> and strndup_user() return EFAULT if length == 0
<bbrezillon> shadeslayer: oh, and given Thomas concern, I don't think you should automatically fallback on the the default GEM function
<bbrezillon> just return -ENOTSUPP if the hook is not implemented
raster has joined #panfrost
<shadeslayer> bbrezillon: ack
davidlt has joined #panfrost
NeuroScr has joined #panfrost
davidlt_ has joined #panfrost
megi has joined #panfrost
davidlt has quit [Ping timeout: 268 seconds]
davidlt has joined #panfrost
davidlt_ has quit [Ping timeout: 240 seconds]
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 265 seconds]
davidlt_ has quit [Ping timeout: 240 seconds]
<shadeslayer> bbrezillon: I'm not exactly happy about copying the label in the IOCTL call tbh https://gitlab.freedesktop.org/shadeslayer/linux/commit/b44d5be7408fba59aa829a9e54765a7e01474f8c
<shadeslayer> and I'm a bit lost on how to hook this into the label vfunc now
<bbrezillon> shadeslayer: because of the extra copy this might generate?
<shadeslayer> bbrezillon: well, the extra copy is going to be generated anyway, I'm a bit unhappy about the aesthetics of that function signature :P
<shadeslayer> where I'm copying args->label and the kernel space label
<shadeslayer> we *could* allocate a new drm_label_object in the ioctl and populate it with the copied string/handle/lenght
<shadeslayer> *length
<shadeslayer> and pass that instead
<bbrezillon> you can just pass the string directly
<bbrezillon> nevermind, you need the BO handle too
<shadeslayer> ^^
<bbrezillon> well, maybe letting drivers deal with the copy is fine for now
<bbrezillon> it's likely to be discussed on the ML anyway
<shadeslayer> yeah
<bbrezillon> so just send what you have
<shadeslayer> bbrezillon: we're still missing the vfunc hook assignment
<bbrezillon> should be done by drivers
NeuroScr has quit [Quit: NeuroScr]
<shadeslayer> ohh, so each *driver* would need to allocate that :(
<shadeslayer> oh well
<bbrezillon> allocate what?
<shadeslayer> the vfunc assignment?
<bbrezillon> the vtable shouldn't be allocated
<bbrezillon> maybe I'm missing something
<shadeslayer> bbrezillon: what I meant was that this won't be available to the drivers 'for free'
<shadeslayer> and that they'd have to opt in
<bbrezillon> yes, that's pretty much was Thomas was asking for
<shadeslayer> aha, I see
<bbrezillon> if you start adding this feature for everyone, that means you ignore the risk reported by Thomas
<shadeslayer> things make more sense now
<shadeslayer> right
<bbrezillon> alyssa, tomeu: what should we do if we find a bug in a deqp test?
<shadeslayer> rejoice? :P
<bbrezillon> I just realized some dEQP-GLES2.functional.color_clear.* tests are failing because they don't disable the scissor test
<bbrezillon> at the end of the ->iterate() method
<bbrezillon> I mean ColorClearCase::iterate()
<bbrezillon> and then they do a clear that they expect to cover the whole FB
fysa has joined #panfrost
<shadeslayer> bbrezillon: v2 sent
davidlt has joined #panfrost
<alyssa> bbrezillon: ...nice
enunes has quit [Ping timeout: 265 seconds]
enunes has joined #panfrost
<bbrezillon> alyssa: well, I think it a mix of a bug in panfrost and a bug in deqp
<bbrezillon> we re-use batches with pre-existing draws in the clear path
<bbrezillon> but we should probably freeze the existing batch and create a new one in that case
<bbrezillon> alyssa: doing that fixes 78 tests, but regresses one :-(
<bbrezillon> weird, the test is NotSupported, but deqp-volt reports it as failed
<bbrezillon> tomeu: ^
Elpaulo has joined #panfrost
davidlt has quit [Ping timeout: 245 seconds]
davidlt has joined #panfrost
<shadeslayer> mmmm .... everyone jumping on the labelling bandwagon
<shadeslayer> confused by what Thomas wants though, surely he could just call drm_gem_set_label with the relevant args?
<bbrezillon> warpme_: Hi
<bbrezillon> I tried to compile mythtv
<bbrezillon> mythtv-setup seems to work here
<bbrezillon> can you help me reproduce the problem you have?
pH5 has quit [Quit: bye]
jernej has quit [Remote host closed the connection]
jernej has joined #panfrost
fysa has quit [Read error: Connection reset by peer]
raster has quit [Remote host closed the connection]
pH5 has joined #panfrost
yann|work has joined #panfrost
yann|work is now known as yann
<bbrezillon> warpme_: the commit has been reverted, but I'd still like to understand why the new logic doesn't work
davidlt has quit [Remote host closed the connection]
davidlt has joined #panfrost
stikonas has joined #panfrost
<warpme_> bbrezillon: regarding mythtv testbed: to reproduce You need: running mythtv backend (server) and mythfrontend (client). For testing on arm he You need compile special branch of mythfrontend (with revorked OpenGL stuff, etc). All this is quite complicated process... To save Your precious time - maybe I can help i.e. by remote testing code changes on my environment (minimyth2 cross-compile build system)?
<warpme_> he->hw
fysa has joined #panfrost
<bbrezillon> warpme_: you'll have to revert the revert if you update mesa
<warpme_> sure. pls give me few min (i'm fixing gstreamer html5 playback on x86_64 arch). Will return to You soon ;-p
belgin has quit [Quit: Leaving]
<warpme_> bbrezillon: as baseline I compiled current master. it works ok. next i'm trying to apply change You propose and I'm getting: checking file src/panfrost/midgard/midgard_schedule.c
<warpme_> Hunk #2 FAILED at 687.
<warpme_> Hunk #1 FAILED at 672.
<warpme_> 2 out of 2 hunks FAILED
davidlt has quit [Ping timeout: 268 seconds]
NeuroScr has joined #panfrost
<warpme_> bbrezillon: ok I compiled master, revert the revert and applied change: nok (screen is white)
belgin has joined #panfrost
fysa has quit [Read error: Connection reset by peer]
<CrystalGamma[m]> c
<CrystalGamma[m]> oops wrong window
pH5 has quit [Quit: -_-]
Kwiboo has quit [Quit: .]
Kwiboo has joined #panfrost
Kwiboo has quit [Client Quit]
Kwiboo has joined #panfrost
Kwiboo has quit [Client Quit]
Kwiboo has joined #panfrost
TheKit has quit [Ping timeout: 244 seconds]
TheKit has joined #panfrost