00:44 AndrewR: hi all ..I updated xf86-video-nouveau, and it started to report some "failure to allocate surface": https://pastebin.com/kvM1mmiQ harmless, so far (uptime 9h)
00:56 imirkin: AndrewR: hm, did i push the wrong thing?
00:56 imirkin: or did you always get a lot of "-2" errors before?
00:58 imirkin: hmmmmm
00:58 imirkin: i wonder if https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=ef89b3c5ca9b2569ca61a9452d13a93edc832810 is too ambitious
00:58 imirkin: for the flip_check
00:58 imirkin: maybe that gets called unnecessarily
00:58 imirkin: or ... something
01:13 AndrewR: imirkin, I saw some "-2" errors before but I assumed they were from kernel or something ....
01:13 imirkin: i just added more info each time it happens
01:14 AndrewR: imirkin, sorry, was away , trying to make some tea....
01:14 AndrewR: imirkin, yeah, I wonder who makes those failed operations ...qt3? :}
01:14 imirkin: who is this peer who keeps disconnecting me...
01:48 imirkin: AndrewR: do let me knwo if it feels like you're getting more of the -2 errors
01:48 imirkin: it's conceivable some of the other changes affect that
01:50 AndrewR: imirkin, OK but for now dog is waiting behind me .....
01:52 imirkin: :)
02:15 imirkin: AndrewR: basically those messages happen when you're way low on vram
02:20 AndrewR: imirkin, I thought 384Mb should be ok for mozilla + some usual mostly gtk2/qt3 things ? (but there still no way to get 'real' vram usage with nouveau, even with kernel 5.4? I'm on old and relatively stable _for me_ 5.1.12)
02:20 imirkin: it'll have more to do with your userspace
02:20 imirkin: programs have started to do a lot of GL things
02:22 AndrewR: imirkin, yeah ..while I think keepen even mozilla (seamonkey) and libreoffice recompiled for gtk2 usage should keep thing a bit 'in old way' ..?
02:23 imirkin: yeah
02:26 AndrewR: imirkin, also, i think I found some heavyweight way to see kde5 on my system - run qemu + virgl + Kde neon it was sorta working this way without guest crashing (but I haven't tried kmail, i remember new kmail was causing a lot of trouble with real nouveau ...)
02:27 imirkin: or just run it with LIBGL_ALWAYS_SOFTWARE=1
03:08 AndrewR: imirkin, yeah, if there is no other way. I was about to ask how fast/slow was tnt2 after you connected your 1920x1200 monitor to it ...but guess for now I'll go to bed and try to sleep ...Good luck, and thanks for all your work!
03:14 imirkin: i dunno - i don't use kde or any of that junk
03:14 imirkin: my regular stuff was plenty fast on tnt2
03:15 imirkin: much as it was back in '99
03:23 AndrewR: imirkin, back in 99 only few had such big monitor :}
03:24 imirkin: i had 1600x1200
03:24 imirkin: sony trinitron
03:24 imirkin: (ok, maybe i only got it in 2000, i forget)
03:26 AndrewR: imirkin, and I had 640x480 and 800x600 driven by 1Mb s3tri64V+ in 2002 :}
03:27 imirkin: heh. i remember that card. i think i had that in like 98 or so
03:27 imirkin: driving a theoretically 1024x768 monitor but i could push it to 1152x864
03:28 AndrewR: imirkin, but with all vrma eaten by visible are a there was nnothing left for video overlay :}
03:28 imirkin: heh
03:28 imirkin: oh wait, i had like a s3virge dx or something
03:30 AndrewR: imirkin, with tons of variants of them, I think one I saw had some problem with specific Xfree version i had on one live cd exactly specialized in video playback (mplayer + wmaker, may be?)
03:31 imirkin: heh
03:31 imirkin: there was no mplayer back then
03:31 imirkin: it was avifile iirc
03:31 AndrewR: in 98 - sure .....
03:32 AndrewR: I was playing with those live cd's in 2003 .... and up ....
03:34 AndrewR: Oh, I have something more to ask ..remember this Playstation 3 Linux saga? There was some attempt at accelerated X driver byut then Sony killed whole Linux on PS3 thing with update ....
03:36 AndrewR: https://www.youtube.com/user/renerebe/videos - I think this developer tried to restart some of this work ....
03:37 AndrewR: remotely topical due to GPU in PS3 being relative of nv40 ?
03:54 imirkin: yeah
03:54 imirkin: what about it?
03:56 AndrewR: imirkin, may be someone want to help (even if ..in youtube comments...)
03:57 imirkin: meh
03:57 imirkin: if he has questions, he knows where to ask
03:58 AndrewR: imirkin, I think sometimes both sides assume other side will do first step, so none does
03:58 AndrewR: imirkin, but ...right now I think I *really* GTS (go to sleep)
03:58 imirkin: sounds good to me
03:58 AndrewR: :}
07:02 kherbst: uis: I am able to reproduce your issue
07:02 kherbst: soo.. let's see
07:05 kherbst: ehhh
07:06 kherbst: that's codegen being super stupid
07:06 kherbst: imirkin: it's the known "we have too many textures" issue
07:06 kherbst: just in this case, it's just two, but a lot of tex operations
07:07 kherbst: https://gist.githubusercontent.com/karolherbst/9214680816fa1c981e46b20d1e6570af/raw/9e3d32f2b7d33301ac5550011b46ae252dd3b988/gistfile1.txt
07:21 karolherbst: heh.. RA does.... nothing
07:24 karolherbst: okay.. let's make that TGSI a little smaller
07:33 karolherbst: https://gist.github.com/karolherbst/9214680816fa1c981e46b20d1e6570af
07:35 karolherbst: that we have to spill here is totally wrong anyway
07:35 karolherbst: soo.. nothing has to get spilled, but RA fails to allocate registers
07:49 karolherbst: yay, cut the temporaries by 66%
07:50 karolherbst: so.. 11 temporaries, which are 44 registers
07:50 karolherbst: 20 "blocked" by out: 20 + 44 > 63
07:50 karolherbst: uff
07:51 karolherbst: ehh...
07:51 karolherbst: I can get rid of more temps actually
07:53 karolherbst: slowly it becomes debugable
10:21 karolherbst: okay.. I think I can't think I can make that shader any smaller
10:21 karolherbst: 56 instructions now... so that's small enough I think
14:10 karolherbst: uff... I am seriously thinking about replacing our entire RA code with util/register_allocate.h
14:10 karolherbst: that should at least have less bugs than ours
15:28 imirkin_: karolherbst: the issue is in the attempt to redo RA
15:28 imirkin_: basically we don't clean up sufficiently between runs
15:28 imirkin_: when two values are merged
15:28 imirkin_: we merge their uses
15:29 imirkin_: and we don't properly unmerge those uses
15:29 imirkin_: or something along those lines
15:29 imirkin_: i tried to fix it, but gave up
15:29 imirkin_: i also briefly considered using the shared register_allocate thing
15:29 imirkin_: but it's not a panacea either
15:30 imirkin_: if you're going to invest significant time into nouveau, i think you realize there are more important issues to address.
15:30 karolherbst: imirkin_: no, that's not the issue
15:30 karolherbst: the first run doesn't do anything
15:30 imirkin_: "doesn't do anything"?
15:30 karolherbst: yeah
15:30 imirkin_: not sure what that means?
15:31 karolherbst: imirkin_: shader after the first round: https://gist.github.com/karolherbst/e7c5aa8ce30d31f87682da788510a40a
15:31 karolherbst: obviously there is no need to spill here
15:31 karolherbst: something funky is going on
15:31 imirkin_: run with DEBUG=255
15:31 imirkin_: should tell you what's up
15:32 imirkin_: damn that's a lot of outputs =/
15:32 karolherbst: well...
15:32 karolherbst: did you try with my most updated shader?
15:32 imirkin_: i haven't tried anything
15:32 karolherbst: ahh
15:32 imirkin_: i'm just looking at the shader
15:32 karolherbst: the output ain't that bad
15:32 imirkin_: 20 regs
15:32 imirkin_: out of 64.
15:33 imirkin_: nothing life-threatening, of course
15:33 karolherbst: https://gist.github.com/karolherbst/8244b9dd0c1281efc6b9aeb3f913f66e
15:33 imirkin_: mostly remarking on it being a lot of outputs :)
15:33 karolherbst: yep
15:34 imirkin_: yeah, so it just fails.
15:34 karolherbst: at some point the weight is inf
15:34 karolherbst: but...
15:34 karolherbst: didn't dig deeper yet
15:34 karolherbst: I am sure it's something stupid
15:35 imirkin_: so basically by the time it gets to that texlod CUBE thing
15:35 imirkin_: there aren't 4 sequential regs available
15:35 imirkin_: (the final texlod CUBE)
15:36 imirkin_: right
15:36 imirkin_: so
15:37 imirkin_: the BASIC problem is that it doesn't realize that it can just "move" those final exports further up
15:37 imirkin_: so they end up double-allocated
15:37 imirkin_: during RA
15:37 karolherbst: ohhh
15:37 imirkin_: i think.
15:37 imirkin_: i.e. it has pre-allocated regs 0..19
15:37 imirkin_: but then those values also need regs
15:37 imirkin_: before they're stuffed into the right regs
15:37 imirkin_: now eventually it all gets simplified and there's no extra move
15:38 imirkin_: (usually)
15:38 imirkin_: anyways, i _think_ that's what may be going on
15:39 karolherbst: mhhh, when I do "14: MOV OUT[4], TEMP[6]" -> "14: MOV OUT[4], TEMP[5]" it succeeds and leaves movs at the end though
15:39 imirkin_: that's coz TEMP[6]'s result got DCE'd
15:39 karolherbst: right
15:40 karolherbst: when I do "13: MOV OUT[3], TEMP[5]" -> "14: MOV OUT[3], TEMP[6]" instead, it still works ;)
15:40 imirkin_: again, stuff gets DCE'd
15:40 karolherbst: what stuff?
15:40 karolherbst: everythnig is still used
15:40 imirkin_: TEMP[5]
15:40 karolherbst: nope
15:40 imirkin_: oh
15:40 karolherbst: it's used
15:40 imirkin_: i see
15:40 imirkin_: sucks, huh :p
15:40 karolherbst: yeah...
15:40 karolherbst: but I'd blame the output handling as well
15:41 imirkin_: i blame canada.
15:41 karolherbst: maybe... two outputs need to move?
15:41 karolherbst: or rather two vec4 values
15:41 karolherbst: and that causes some weird fallout somewhere
21:02 Lyude: imirkin_ / rhyskidd: fwiw, I just sent out an email to a few mailing lists to see who all would be interested in VESA memberships. Are either of you two interested (and up to date on your X.org memberships?)
21:05 imirkin_: i saw the email
23:42 mooch: Lyude, did that nvidia guy ever get back to you about the riva 128 docs?
23:44 Lyude: mooch: no, because i forgot to ask whoops ;_;
23:44 Lyude: I will make sure to ask first thing on monday
23:45 mooch: ah, sorry
23:45 Lyude: hehe, not your fault
23:45 Lyude: thanks for reminding me