<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/sun4i-drm_dri.so
<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]
<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...
<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]