00:49Decuke: Hi everyone, i got some problems especifically while running League of Legends using gallium nine on NVE4 and Axeldavy told me to get here
00:50Decuke: my performance goes to trash while i scroll the camera to the boundaries of the game and i get these errors : http://pastebin.com/EcfHSgn8
01:06gnarface: Decuke: does it freeze or lock up when that happens?
01:08gnarface: Decuke: sorry i'm sure someone currently asleep knows more than me, but the best of my google-fu suggests you should try a newer kernel
01:08gnarface: Decuke: personal experience suggests an older one might work too (but might also regress in performance)
01:08Decuke: im on 4.10.1
01:08Decuke: and was experiencing this on 4.9
01:09gnarface: by older i meant like... 3.16
01:09gnarface: what distro are you on?
01:10gnarface: what mesa version? (just out of curiosity)
01:10skeggsb: looks like clear_render_target and/or clear_depth_stencil are being called with negative args..
01:10Decuke: testing enabled, but non testing kernel//mesa version gets same error
01:12Decuke: on Gallium9 side of things i get this
01:12Decuke: fixme:d3d9nine:Direct3DShaderValidatorCreate9 Returning interface 0x1e2e7540
01:12Decuke: but stops
01:12Decuke: and dmesg still reports more warnings
01:13Decuke: even without fixmes on wine
01:13gnarface: Decuke: when it happens the system doesn't freeze though?
01:15Decuke: no, the fps drops a lot and goes downhill up to a time that i get 6-10 fps and stutters a lot
01:16Decuke: started a match rn
01:16Decuke: in 20 minutes im on [ 4441.205313] nouveau 0000:01:00.0: gr: DATA_ERROR 00000004 [INVALID_VALUE] ch 17 [00fe5f8000 Xorg] subc 0 class a097 mthd 0ff8 data fffffff6
01:19gnarface: this sounds worthy of a bug report
01:19skeggsb: Decuke: see my comment above
01:20gnarface: i'd kinda be surprised if there isn't already one
01:20skeggsb: nfi if it's nine passing bad args, or we need to handle them..
01:21Decuke: makes sense
01:23Decuke: im trying to regress to mesa 13.0 again (i was trying to do this before reporting the error here but libglvnd incompatblities got me on the heel)
01:23Decuke: well brb
01:24gnarface: yea i'd also be curious if an older mesa could help here, but my interest is purely academic here. i can't actually help
01:33Decuke: mesa 13.0 and i got the same error
01:33Decuke: yup, seems to be kernel related
01:35Decuke: will try 4.4 LTS and im pretty sure i wont have problems ( im on 4.10 now and had these problems on 4.9.11 too)
01:35skeggsb:really doubts that
01:41Decuke: on 4.4 now, gonna play for 20m
01:41Decuke: ARGH DOESNT EVEN NEED THAT
01:41Decuke: [ 120.225854] nouveau 0000:01:00.0: gr: DATA_ERROR 00000004 [INVALID_VALUE] ch 14 [00fe8c9000 Xorg] subc 0 class a097 mthd 0ff8 data fffffff6
01:42gnarface: one begins to suspect this never worked
01:42Decuke: FML skeggsb u right
01:42gnarface: also whether it can be avoided by changing the game's own graphical options
01:42Decuke: all on minimal
01:42Decuke: still gets low fps
01:42Decuke: my fps starts at 300
01:43gnarface: i was thinking maybe this is caused by one particular graphical effect
01:43Decuke: anyway, it probably faulty hardware or what skeggsb said about clear_render_target
01:44Decuke: gnarface, which effect?
01:45gnarface: Decuke: oh i didn't have a particular one in mind. the fact you're still getting it on all minimal settings does sorta shoot down that theory actually. wouldn't necessarily rule out faulty hardware either.
01:45skeggsb: the behaviour would be a lot less specific if it were faulty hw
01:45Decuke: i think that too ben
01:46gnarface: Decuke: i just thought, theoretically, maybe some sort of shader-model-5 specific graphical effect or something like that, for example
01:46skeggsb: mesa (whether that be nine, or something else) is passing bad args to the driver
01:46skeggsb: the functions take unsigned args, so, i don't think we're meant to handle negatives either
01:46Decuke: using any type of GL would actually trigger this too someway
01:46Decuke: i even tested using 4.5 experimental support and nothing like that using GL
01:56Decuke: well I'm almost sure i wasnt experiencing this 3 months ago using nine, never got up to unplayable fps and lots of stutter on a long game like i get now
01:56Decuke: i suppose there is change in the game renderer
01:57Decuke: since downgrading everything and going back to dri2 didnt helped at all
01:57Decuke: what can i do to help profile and find this?
01:58gnarface: there's gotta be some place to file a bug report...
02:01gnarface: Decuke: i think the general rule of thumb is to report the bug directly to your distro maintainers' official channels first, as bugs forwarded by them directly to the kernel team will probably get more attention
02:03gnarface: Decuke: also i found this: https://nouveau.freedesktop.org/wiki/Bugs/
02:09Decuke: i know freedesktop bugzilla, but yeah, i was trying to get more info before filling a proper bug
02:10gnarface: if you could find a way to reliably reproduce it with only open-source software, that comes to mind as a good thing to include in the bug report.
02:10gnarface: something that only is reported as happening to League of Legends isn't likely to get much traction from kernel devs, i'd guess
02:11Decuke: also i was hopeful about getting a working version even if it was a unreliable/bad coded patch or hints to doing this myself
02:11Decuke: i only get these errors using wine nine so i will need to find another propietary tool as example
02:12gnarface: yea i feel ya there. :-/ happening in kernel 4.4 - 4.10 though is prohibitive there
02:12gnarface: quite a wide range of kernels
02:12gnarface: it'll be hard to boot an older kernel with such a new userspace and expect any opengl acceleration to work
02:12gnarface: maybe you could dig out an old debian/ubuntu/knoppix livecd or something perhaps? see if it still happens all the way back in kernel 3.x
02:13Decuke: well if it happens it will prove my newest theory : it was a LoL render change/update
02:14gnarface: your wine version didn't change in there?
02:14gnarface: because of course another possibility if it did, is that it was a LoL rendering feature that was always there but that wine only recently added *support for*
02:15Decuke: i tried using 2.0rc3-2.2 with nine patches
02:15Decuke: i could try wine 1.9.23
02:16Decuke: the only thing i dint test extensively was wine, did not test pre 2.0
02:16gnarface: alternately to changing wine versions, you could also do stuff like just, disable GLSL or multisampling in the registry
02:16Decuke: but mesa tried 13.0-17.1-dev
02:18Decuke: i dont think fuzzing registry stuff will change much, the only thing i needed to play league was installing d3dx9 and the game was playable
02:19Decuke: im on mesa 13 with 4.4LTS kernel right now
02:20Decuke: going to use Playonlinux and try different wine versions
03:15skeggsb: anyone around with a gm10x plugged in, that's willing to peek some regs for me? ;)
10:52dboyan: karolherbst, I found today that mmiotracing of nvenc seemed to hang with cuInit.
10:53dboyan: karolherbst_: cuInit won't hang on 340 driver, but codec can't be correctly initialized
10:54karolherbst_: what a mess
10:54karolherbst_: I may find some time this weekend to look into this
11:00dboyan: karolherbst: I have two mmiotraces captured when running nvenc demos
11:01dboyan: The 375 one is magically saved while blindly sysrq magics
14:01karolherbst: RSpliet: :D as it seems, you don't have to worry living in the UK forever anymore! :D
19:37RSpliet: karolherbst: ?
19:43pmoreau: RSpliet: I guess he is referencing to the House of Lords amending the Brexit bill
19:44RSpliet: oh, yeah, it's nice to discover that there's some lords who care about people like me... May on the other hand
19:44RSpliet: This battle isn't over just quite yet
19:45pmoreau: bbiab, gotta catch the bus.
21:09karolherbst: uhh glretrace: /var/tmp/portage/x11-libs/libdrm-2.4.75/work/libdrm-2.4.75/nouveau/pushbuf.c:727: nouveau_pushbuf_data: Assertion `kref' failed.
21:10karolherbst: pmoreau: any ideas how I should debug this?
21:10karolherbst: it's inside nve4_launch_grid+0x749aff:
21:11karolherbst: (trying out that hitmanpro trace for the radon bug)
21:11orbea: multithreaded GL?
21:11karolherbst: I idea yet
21:12karolherbst: if it's triggered in the same call over and over again then not, but I didn't run it a second time yet
21:14imirkin: karolherbst: multithreading isn't a concern with glretrace iirc
21:15imirkin: what that assert is saying is that you're trying to do nouveau_push_data() with a bo that's no ref'd
21:15karolherbst: only if I force singlethreaded?
21:15imirkin: i.e. that hasn't had a nouveau_pushbuf_refn() on it
21:15karolherbst: I see
21:15karolherbst: well, I have a month old mesa right now
21:15karolherbst: will replay with an updated one
21:15imirkin: so normally you do like
21:15imirkin: PUSH_REFN(bo); nouveau_pushbuf_data(bo)
21:16imirkin: coupled with some PUSH_SPACE beforehand which ensures that there's no kick due to the PUSH_REFN
21:16karolherbst: I see
21:16karolherbst: should be easy to figure out what is wrong then
21:17imirkin: i haven't looked at the code in there directly... guessing it's a glDispatchComputeIndirect() call
21:17karolherbst: sad that the window stays black :/
21:17imirkin: so it does the space thing for 16 elements
21:18karolherbst: I hoped I could just replay the radeon trace
21:18imirkin: then writes 5
21:18imirkin: and then does the pushbuf_data
21:18imirkin: this won't work.
21:18imirkin:shakes fist in anger
21:18imirkin: karolherbst: switch that 16 -> 32
21:19imirkin: this guy.
21:21karolherbst: crash in same call at least
21:32karolherbst: imirkin: glretrace: ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp:1254: bool nv50_ir::NVC0LoweringPass::handleTXLQ(nv50_ir::TexInstruction*): Assertion `(i->tex.mask & ~3) == 0' failed.
21:39ievms: could a irc admin here add the "s" to the link in the chat topic? Its missing. Here the fixed link: https://people.freedesktop.org/~cbrill/dri-log/index.php
21:40ievms: and: https://nouveau.freedesktop.org/
21:40karolherbst: mhhh, I would if I could
21:40karolherbst: skeggsb this is for you? no idea how is able to
21:42ievms: karolherbst: could you take a look into the critical and fully broken nv40 part of nouveau? I am reporting this since over 1 year and nothing happened till now
21:42karolherbst: I have no such gpu
21:42ievms: i can spend you 5euro/dollar to get such one
21:43karolherbst: if you give me money for a motherboard and cpu as well, I could buy one
21:44ievms: you dont have any?
21:44karolherbst: but there was a bit of work regarding nv40, so what is broken especially so that it doesn't work
21:44ievms: its fully broken on plasma, its broken on gnome, its broken in 3d games, ... should i continue?
21:45karolherbst: depends on what you mean by broken
21:45karolherbst: there are issues regarding multithreading stuff in nouveau, but this relates to all GPUs
21:46karolherbst: which gets hit by plasma5 especially
21:46ievms: you start plasma, you get kde-login animations, you see full screen of colored lines, done. Machine not working any more. Is that broken enough?
21:47imirkin: karolherbst: can you file a bug with the TGSI?
21:47karolherbst: imirkin: yes
21:47karolherbst: also the 32 patch didn't work
21:48karolherbst: is the crash
21:48ievms: imirkin: could you add the s to the links above? The correct links are: https://nouveau.freedesktop.org/ and https://people.freedesktop.org/~cbrill/dri-log/index.php
21:48imirkin: that's a different line
21:48imirkin: which has the same problem
21:48karolherbst: ievms: did you file a bug report?, usually things get forgotten if you only report it inside IRC
21:48karolherbst: imirkin: another +16?
21:49imirkin: karolherbst: yes.
21:49karolherbst: so stuff + 24 in this line
21:49ievms: karolherbst: imirkin probably have not forgotten the fully broken nv40. skeggsb also have not forgotten the broken nv40
21:49imirkin: ievms: what's wrong with the link as-is?
21:49imirkin: ievms: also, nv40 is in the same state it always has been. you're throwing applications that were never meant to run on it, and then wondering why they don't work.
21:49ievms: karolherbst: but yes, there are many bugreports. I can link you some if you like
21:50karolherbst: well sure there are many, but is there one covering _your_ situation?
21:50ievms: imirkin: the servers support https. The http links allow MITM attacks on first use and are a security problem because of that
21:50imirkin: ievms: use software that was designed to run on a nv40. i.e. not gnome-blah
21:51karolherbst: well, we could fix the crashes or odd things though
21:51karolherbst: except it comes from unsupported GL extensions
21:51imirkin: ievms: but then i'd be updating the topic for the first time in 6 years. hardly seems worth it.
21:51imirkin: karolherbst: you make it sound easier than it is :p
21:51karolherbst: that's how I am
21:51ievms: imirkin: yes, please update the topic the first time after 6 years
21:52karolherbst: imirkin: I put a "nouveau_pushbuf_data(push, res->bo + 16, offset + 8," in this line, didn't work
21:52imirkin: karolherbst: lol
21:52imirkin: karolherbst: you want to update nouveau_pushbuf_space, above
21:52karolherbst: I see
21:54karolherbst: imirkin: you want to post it on the ML/push the patch or should I post it? (after I verified it improves the situation)
21:54imirkin: hakzsam: btw, i think that aligning texture buffers to 256 on fermi is right. you can bind a tbo to an image slot, and it can have an offset. if we don't force the offset alignment to 256, then the address of the buffer can end up having a "tail". so that's why i'm just forcing alignment to be 256 there.
21:54imirkin: karolherbst: wtvr
21:55karolherbst: I get some unaligned errors
21:55imirkin: karolherbst: ...?
21:55karolherbst: while replaying the trace, wait a sec
21:55karolherbst: GL_INVALID_VALUE in glBindBufferRange(offset misaligned 132160/256)
21:55karolherbst: and a lot of those
21:55imirkin: ah right
21:55imirkin: that makes sense
21:55imirkin: you took a trace from radeonsi
21:55karolherbst: I see
21:56karolherbst: okay, replacing those 16 with 32 indeed improved the situation
21:56imirkin: it has different alignment requirements
21:56karolherbst: still wanna have that TGSI or will this be a similiar issue?
21:56imirkin: totally different
21:56ievms: imirkin: could you please fix the links. This is security relevant part. I think that should be votet as important. The site-admins have spend time to make the websites secure. please use this security
21:57imirkin: LODQ should really only provide .xy output in the destination... that assert is hit if someone's trying to get .zw outputs, which are unspecified.
21:57imirkin: ievms: ok. i will not be making the update.
21:59ievms: imirkin: Why "ok" when you disagree? Have i misspelld something?
21:59imirkin: ievms: no, everything you say is absolutely, 100%, correct
22:00imirkin: however i'm insufficiently inclined to change the topic
22:00ievms: i look up now what "insufficiently inclined" mean
22:00karolherbst: imirkin: because I have no idea what I just did there, you could improve the commit message a bit or so: https://github.com/karolherbst/mesa/commit/0938633dd9dd8ad11fac9baf854140607d8dac6c.patch
22:01karolherbst: or _why_ I had to do this
22:01imirkin: karolherbst: look at this commit message for inspiration...
22:01imirkin: [gimme a sec]
22:02ievms: imirkin: who else can i ask to fix the topic?
22:02imirkin: karolherbst: eb60a89bc3ac2b43faf52d06e05670bbbca7292d
22:02ievms: imirkin: should i fill up a bug on the bugtracker?
22:04karolherbst: imirkin: better? https://github.com/karolherbst/mesa/commit/08c65d5054332cbe2d53c437fcee155299143cbc.patch
22:05imirkin: karolherbst: could use some work.
22:06karolherbst: and I need some sleep :D
22:06imirkin: hehe ok
22:08karolherbst: I guess michael will be happy doing benchmarks if we fix those crashes :D
22:09imirkin: karolherbst: do file a bug with the TGSI, i'll take a look at it
22:09karolherbst: will do
22:09karolherbst: shouldn't be as important though, because it's just a assert in a dev build
22:10karolherbst: I will tag the right versions to send the patch as a CC to
22:11imirkin: (and the glsl shader that generated it, ideally)
22:11karolherbst: will try
22:11karolherbst: well, I know the gl call number...
22:11imirkin: well, it's kinda important - the resulting shader will be potentially wrong
22:12karolherbst: true, but fixing crashes is like a bit more important than fixing visual artefacts
22:14imirkin: yeah, but i added LODQ back in the day - means i messed up somewhere ;)
22:16karolherbst: shaders are like super small which generate this error
22:16imirkin: great ;)
22:28karolherbst: now how to hit the assert with piglit :D
22:29ievms: karolherbst: here a example bugreport for broken nv40: https://bugs.freedesktop.org/show_bug.cgi?id=99581
22:30ievms: karolherbst: an other one: https://bugs.freedesktop.org/show_bug.cgi?id=98631
22:31skeggsb: ievms: you're not telling us anything we don't already know...
22:31karolherbst: imirkin: I guess you just get the TGSI.... :/
22:31ievms: karolherbst: other one: https://bugs.freedesktop.org/show_bug.cgi?id=96460
22:31imirkin: karolherbst: :(
22:31imirkin: karolherbst: if you know the call number
22:31imirkin: and can point me at the trace
22:31imirkin: then i can figure it out myself
22:32imirkin: my desktop's still all packed up, so i can't actually test anything
22:32ievms: skeggsb: could you fix the topic in this irc channel?
22:32ievms: skeggsb: The correct links are: https://nouveau.freedesktop.org/ and https://people.freedesktop.org/~cbrill/dri-log/index.php
22:32karolherbst: imirkin: https://gist.github.com/karolherbst/aa3d279494da2a234a4a2c2ea75ad37a
22:33imirkin: karolherbst: huh. odd. so it tries to write all 4 channels.
22:33karolherbst: well, it's OpenGL 4.5
22:33imirkin: that's definitely odd.
22:33imirkin: nah, this is textureQueryLod() which returns a vec2 :)
22:33karolherbst: I see
22:33karolherbst: I just meant that the game uses 4.5
22:34imirkin: ok, and where is the trace?
22:34karolherbst: imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=99923#c6
22:35ievms: skeggsb: i simply didnt know what to do. nv40 is crashing on any usecase here and i am reporting this for many months. If i start flooding the bugtracker with logfile for tons of different usecases, would this get a higher priority on Red Hat?
22:35skeggsb: no, because there are *several* newer generations that people use a LOT more that have a MUCH higher priority
22:36skeggsb: unfortunately, there's not a lot of us, and way too much work to do
22:36imirkin: ievms: you may be happy to know that i recently bought a GeForce 6200 PCI card. which means i can plug it into my desktop without sucking up a pcie slot.
22:36karolherbst: ievms: your best chance is to learn about nvidia GPUs and fix it yourself, sorry, but that's how it is for now
22:36karolherbst: or ask imirkin very nicely :D
22:36skeggsb: i'd *love* to have the manpower to make everything work perfectly, but, that's a pipe dream
22:36karolherbst: skeggsb: you aren't loud enough then ;)
22:37imirkin: skeggsb: btw, great work on the GTX 970 issue :) and sounds like you fixed the GF108 thing simultaneously -- someone was in complaining about that the other day
22:37ievms: imirkin: great!
22:37skeggsb: imirkin: well, i broke gm10x in the process ;)
22:37skeggsb: fixing that now
22:37imirkin: skeggsb: hehe, can't win 'em all. i have one in my desktop, although my desktop is in a cardboard box for now.
22:38ievms: imirkin: what are the plans of using it?
22:38imirkin: ievms: well, some bugs come up every now and then which i ought to be able to fix. unlikely to fix the types of things you're talking about as i refuse to pollute my system with gnome/kde crap
22:40imirkin: however there are a lot of aspects of things that we could be doing a lot better on, and i may try to improve some of them. perhaps that'll trickle down into improvements for the gnome's/kde's of the world
22:40ievms: imirkin: when finding any bug outside of gnome/kde, how should i ping it to you? Just fill up a bugreport "for imirkin: ... "?
22:41imirkin: ievms: no, i see all the bug reports that go through. some of them are things i know about, like STK running out of vram -- yeah, that happens :)
22:41imirkin: karolherbst: huh, so the relevant line is: r0.x = (textureQueryLod(resourceSamplerPair_0_ps, v2.v.xy)).x;
22:42imirkin: i wonder if it's the stupid register rewriting thing that's messing things up.
22:42imirkin: anyways, thanks, i'll investigate.
22:43karolherbst: nice :)
22:43karolherbst: should I try to rewrite my commit? Or should I just post it on the ML and CC to you?
22:43ievms: imirkin: could you already find some solution for this "out of ram" problem for example?
22:43imirkin: karolherbst: it definitely needs to be rewritten
22:43imirkin: ievms: no. that's a super-hard problem that i have no idea how to tackle.
22:44karolherbst: well at least nouveau isn't worse compared a linux kernel without swap reagarding the out of memory issue
22:44karolherbst: I guess
22:44karolherbst: or is it?
22:45imirkin: probably much worse.
22:47karolherbst: skeggsb: do you have any idea how I can get the nvkm_clk worker thread to take "arguments" so that I can force a reclock even if the subdev things the right clocks are set.... wait, I could just reset the information about the current state on resume
22:47karolherbst: \o/ yay
22:50imirkin: karolherbst: you can wipe the information about current state in _fini
22:50karolherbst: I have to set it on boot anyway
22:50karolherbst: or well
22:50karolherbst: set it to NULL
22:50karolherbst: but yeah, I could also do it in _fini... but I think it would be better suited in _init
22:53karolherbst: will adjust my patches tomorrow or over the weekend and finally post it on the ML :)