ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at and - Contact ARM for binary driver support!
MoeIcenowy has quit [Ping timeout: 268 seconds]
MoeIcenowy has joined #lima
yuq825 has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
_whitelogger has joined #lima
jrmuizel has quit [Remote host closed the connection]
piggz has joined #lima
<piggz> hi people .... Qt related question.....
<piggz> i was using Mesa 19.1 sort of Ok, but found it buggy, with bshah, I found that master is better....
<piggz> i updated to master, changing nothing else, but now when starting our UI, i get
<piggz> EGL Error : Could not create the egl surface: error = 0x300b
<piggz> i suppose i should test with kmscube like last time!
guillaume_g has joined #lima
<piggz> [root@Sailfish kmscube]# ./kmscube
<piggz> drmModeGetResources failed: Operation not supported
<piggz> failed to initialize legacy DRM
<piggz> ok, -d /dev/dri/card1 helps there.....
<piggz> except it still doesnt work, prints some info and exits...
<piggz> return code is 0
<piggz> sorry, my bad, its -D for device!
<piggz> now, its still doesnt work .......
<piggz> screen changes to a white background but nothing is shown
<piggz> no errors printed
<piggz> if i ctrl-c it displayes the kernel console again
guillaume_g has left #lima ["Konversation terminated!"]
<bshah> piggz: stupid question, you did build ksmro backend right?
hoijui has joined #lima
<piggz> bshah: i was wondering that, let me check my .spec
<piggz> bshah: i believe so, i have the file
<piggz> /usr/lib/dri/
<piggz> which is only built if compiled with kmsro
<bshah> mm okay
RoNaLD` has joined #lima
RoNaLD` has left #lima [#lima]
<enunes> yuq825: we should write a troubleshooting section on the wiki, otherwise people will keep filing reports that desktop environments or qt don't work...
* bshah quietly hides :P
<enunes> I think basically: "try mesa master", "try kmscube before anything else", "if you application hits missing ppir_cf_node or gpir_cf_node, not supported yet"
<wens> enunes: people won't know whether *_cf_node is involved or not
<bshah> wens: tehre's warning in app logs
<enunes> wens: good point, so between those steps we insert "use LIMA_DEBUG=all"
<wens> enunes: at this point a list of what works is probably easier
z3ntu has quit [Write error: Connection reset by peer]
romainmahoux[m] has quit [Remote host closed the connection]
<wens> bshah: you need debug logs for that. X + glamor produces zero warnings by itself, simply a weird looking screen
<bshah> umm not really. without any logging enabled, I got warning in my app saying lima: gpir_cf_node not supported
<bshah> I didn't had to do anything at all for that
<enunes> wens: I see your point, though maybe it encourages some of the reporters to try to obtain the logs to look for that before reporting
calcprogrammer1 has quit [Ping timeout: 240 seconds]
<wens> bshah: X + glamor + lightdm / xfce4 gives nothing. so it's probably application dependent
bshah|matrix has quit [Ping timeout: 276 seconds]
<wens> enunes: a big warning ahead would be nice, then steps to produce logs for the more adventurous and helping ones :)
<enunes> it probably does if you run it manually, like over ssh and not on the screen directly?
dddddd has joined #lima
yuq825 has quit [Remote host closed the connection]
<wens> maybe. I'd expect all messages to be captures in ~/.xsession-errors and I'm not seeing anything related to lima
bshah|matrix has joined #lima
hoijui has quit [Quit: Leaving]
calcprogrammer1 has joined #lima
z3ntu has joined #lima
romainmahoux[m] has joined #lima
calcprogrammer1 has quit [*.net *.split]
calcprogrammer1 has joined #lima
calcprogrammer1 has quit [Changing host]
calcprogrammer1 has joined #lima
dddddd has quit [Remote host closed the connection]
dddddd has joined #lima
yuq825 has joined #lima
jrmuizel has joined #lima
piggz has quit [Read error: Connection reset by peer]
jrmuizel has quit [Remote host closed the connection]
piggz has joined #lima
<piggz> enunes: wens: does this add enything?
yuq825 has quit [Ping timeout: 258 seconds]
yuq825 has joined #lima
<piggz> for info, downgrading to 19.1.3, kmscube wors ok
<piggz> reboot
jrmuizel has joined #lima
<rellla> hey guys, can you have a quick look at this disassembly
<rellla> "$$" is from a quick hack, marking dest...
jrmuizel has quit [Remote host closed the connection]
<rellla> the second gt.s0 has no output_en, so i suspect it goes to a pipeline register.
<rellla> shouldn't this pipeline reg be used in the following add.s1?
<enunes> piggz: that seems like it should be working, if you have a previously working version can you bisect?
<piggz> enunes: i can try, but im going to a festival tomorrow for the weekend, so will take me some time!
<piggz> and, if i sit on my laptop all afternoon, i will get told off by the wife!
<enunes> piggz: well in my setup it works, so the hurry is yours :)
<piggz> enunes: np :)
<enunes> rellla: I would expect the other instruction to use the pipeline reg output, is this with changes you've made? what are you working on now?
jrmuizel has joined #lima
<rellla> i'm trying to add fddx/fddy and i'm struggling with adding a mov for sources of the fddy/x ssa's which have abs or neg set. i want to do this in ppir. because nir lowers abs/neg into the source it makes it a bit more tricky. at least for me...
hoijui has joined #lima
<rellla> ans yes, i have some changes done and this is the actual piglit result
<enunes> rellla: I think you can check if the sources have .negate or .absolute set and create ppir nodes to add before the fddx node and adjust the sources and pred/succ
<enunes> then unset the .negate and .absolute
<rellla> enunes: the way i do it is the following:
<enunes> there should be some similar cases you can use as a copy paste start there
<rellla> lower fddx and fddy, check if src[0].absolute or src[0].negate is set (the src is a ld_var in this example), add a move node with ld_var and the modifiers as the source. use the new move as the source for fddx and unset the modifiers.
<rellla> the problem that i have, is that i get in trouble with setting src, dest, target_assign, replace_child aso ... i always mix it up and therefore get into trouble...
<enunes> yeah it is a bit confusing to work with and there is some boilerplate code to manipulate all that
<enunes> why do you have ld_var?
<enunes> I would expect just movs
<rellla> this is what nir lowers it to i suspect
<enunes> ah, I see, it's just the xample
<rellla> enunes: as i think my implementation is /basically/ right, i look into the disassembly. and here i wanted to see, if $1 of "load.v $1.xy 0.xy" stays untouched until i reach my mov ops. and this is what my first question is about :)
<piggz> enunes: looks like there are 2 things to bisect .... 19.1.0 works with kmscube and jolla-lipstick-ui, 19.1.3 works iwth kmscube but not the UI, and master works with neither!
<piggz> might be easier to bisect between 19.1.0 and 19.1.3 first
Net147 has quit [Quit: Quit]
Net147 has joined #lima
Net147 has quit [Read error: Connection reset by peer]
<piggz> oh, no forgive me, 19.1.3 does work
Net147 has joined #lima
Net147 has quit [Read error: Connection reset by peer]
<enunes> piggz: honestly I think we don't much about 19.1 and especially not stable releases
<piggz> ok
Net147 has joined #lima
<enunes> don't care*
<piggz> (worked it out ;)
<enunes> rellla: register allocation should ensure it makes sense if you're doing that, if not, maybe some src/dest is incorrect? maybe it's easier if you push your commit to a branch
yuq825 has quit [Remote host closed the connection]
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
<rellla> enunes: i have to clean it up first. ...and i have seen, i commented some pieces, which could be responsible. will try it later :)
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
jrmuizel has quit [Ping timeout: 244 seconds]
megi has joined #lima
hoijui has quit [Ping timeout: 264 seconds]
jrmuizel has joined #lima
hoijui has joined #lima
hoijui has quit [Remote host closed the connection]
drod has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
Wizzup has quit [Quit: i/o error, brb]
Wizzup has joined #lima
libv_ has joined #lima
libv has quit [Ping timeout: 245 seconds]
libv_ is now known as libv
drod has quit [Ping timeout: 246 seconds]
drod has joined #lima
<anarsoul> enunes: are you around?
<enunes> anarsoul: now I am
<anarsoul> enunes: I'm working on creating succ/pred lists later
<anarsoul> so far I think that we need to clone const nodes in nir.c to avoid walking non-existent lists in lower
<anarsoul> what do you think?
<enunes> I plan to double check alyssa's suggestion before merging the texture perspective stuff
<anarsoul> I.e. each const node will have exactly one successor
<enunes> yes, duplicating constants is necessary to complete the schedule with pipeline
<enunes> I'm still worried with that because there might be some corner case with an instruction needing more than 2 vec4 constants...
<anarsoul> yeah
<anarsoul> for now it's not handled
<enunes> I think for now we create a move for that
<enunes> but it's only known during schedule time
<enunes> which cycles back into the problem
<anarsoul> well, I'm planning to retain move
<enunes> I think with the 1 op per instruction first rule (well, except for the exceptions) it should be valid to duplicate all of them without needing moves
<anarsoul> enunes: yeah, select with 3 consts will be optimized out anyway
<enunes> I think so too
jrmuizel has quit [Remote host closed the connection]
<anarsoul> I think it should give the basic idea
<anarsoul> if you're OK with it I'll proceed with the rest of lowering functions
<anarsoul> (we need to convert them to actual passes anyway)
drod has quit [Remote host closed the connection]