00:14 mogorva: imirkin: thank you for taking the time to fix bug 91056 :)
00:14 imirkin: mogorva: you're welcome. still plenty more to fix.
00:15 imirkin: but at least i have a nv50-family card plugged in now
00:15 mogorva: do you have any idea what are those black polygons that come from the player's head?
00:15 imirkin: no, but you said that they also appear on other drivers including blob
00:15 imirkin: which to me reads as "not my fault" :)
00:16 mogorva: yes, they're present with the binary drivers too
00:16 imirkin: most likely a wine fail of some sort... should check if they're there with gallium-nine
00:17 mogorva: um.. i reported this bug in the game that runs natively on Linux
00:18 imirkin: oh.
00:18 imirkin: then it's something funny that they're doing :)
00:19 imirkin: maybe an off-by-1 situation... dunno
00:21 mogorva: the windows version under wine has another bug, i'll check it out if it is still present after your fix: https://bugs.winehq.org/show_bug.cgi?id=23863
00:32 imirkin: mogorva: hah, since 2010. long-time bug
00:33 mogorva: yes, your fix in mesa doesn't fix the game under wine
00:33 imirkin: makes sense... i doubt that nvidia blob would have had the same bug, and they apparently fail with it too
00:35 imirkin: this particular one (91056) was specific to having a version of mad (mul + add) which used an indirect constbuf load in its 3rd argument. pretty specific stuff :)
00:40 imirkin: did i ever figure out what the Civ5 issue was?
00:41 mogorva: not yet, you said it wasn't reproducible on your previous hardware
00:48 imirkin: oh dear. it's the FlatteningPass that fails
01:03 imirkin: yeah it's busted
03:25 Samsai: hmm
03:26 Samsai: has anyone tried reclocking a 760 to powerstate 0e/0f recently?
03:26 mupuf: Samsai: this has never been stable
03:26 RSpliet: Samsai: well... not really; is that a GDDR5 or DDR3 card?
03:26 mupuf: gnurou: libdrm 2.4.62 is out :)
03:26 mupuf: update your mesa patch and I will push it
03:27 Samsai: a gtx 760 is a GDDR5
03:27 Samsai: i've tried reclocking to that powerstate recently and it actually seems a lot more stable than it used to
03:27 RSpliet: Samsai: ah, in that case... this has never been stable
03:27 mupuf: hmm hmm
03:27 mupuf: that's interesting
03:27 Samsai: i'd say maybe 8 out of 10 attempts are successful
03:28 mupuf: it is probably linked to the increase of the timeouts on the different buses
03:28 mupuf: that is really interesting
03:28 RSpliet: and/or the temperature :-D
03:28 Samsai: there's one thing about it that is quite puzzling
03:28 Samsai: it seems that only the memory gets reclocked on that powerstate
03:28 gnurou: mupuf: yay! will do, thanks!
03:28 RSpliet: could be, that's the biggest influence on perf
03:29 Samsai: the pstate file says that core clock stays at the lowest clock rate
03:29 Samsai: when i noticed that reaching the highest powerstate was possible i naturally ran some benchmarks
03:30 Samsai: relatively simple stuff like hl2 lost coast ran better, jumped from 80 fps to 100
03:30 mupuf: that's not a big change
03:30 Samsai: but unigine heaven dropped from 29 to 25
03:30 mupuf: gnurou: you're welcome
03:31 mupuf: Samsai: that is ... wierd
03:32 Samsai: now i'm not an expert in any way but i'm guessing the low core clock rate is a potential bottleneck
03:34 mupuf: yes, but increasing the clock of one clock domain should not lower the performance of others unless we are TDP limited
03:34 mupuf: and nouveau is far from handling this!
05:01 nfk: http://www.theinquirer.net/inquirer/news/2415541/microsoft-might-buy-amd-to-restore-its-chip-design-operations // and there goes radeon linux support if the deal happens
05:01 nfk: good thing i haven't bought a raden just yet
05:10 RSpliet: nfk: well, let's not jump to conclusions just now
05:10 RSpliet: as Dutch bankers always say
05:10 nfk: i know, i know but you know what's gonna happen if ms buys out amd
05:10 RSpliet: "Behaalde resultaten in het verleden geven geen garantie voor de toekomst"
05:10 nfk: you could as well have used finnish
05:11 RSpliet: ("Results obtained in the past give no guarantee for the future" ;-))
05:11 RSpliet: nah, Finnish is much further away from English
05:12 nfk: also if that was true generally, then science would be in trouble, al it proves is that economics is not a science
05:12 RSpliet: philosophically speaking science is in trouble, but that's probably not the point
05:12 nfk: whatever
05:13 RSpliet: all I say is that there's no use worrying already. Valve is not going to produce a Windows-based steambox, so MS has a motivation for producing good Linux drivers
05:13 RSpliet: plus it's only rumours, no contract has been signed
05:14 nfk: or ms might destroy amd and be done with it, it's not like they didn't destroy nokia
05:15 nfk: if there was a proper android nokia i'd be using that
05:15 RSpliet: Nokia was worthless before MS obtained them, as dumbphone marketshare was declining rapidly; MS just gave the final push over the cliff with Elop "Trojan Horse"
05:15 nfk: but alas i'm stuck with my old s60 nokia until it lets out the magic smoke and then i'm going for lg or sony or *shrugs* huawei
05:16 RSpliet: I'm stuck with an HP Pre 3 for now, I share your pain
05:16 nfk: RSpliet, that just shows how little you know, s60 is not exactly a dumbphone an they also had the one and only true GNU/Linux phone on sale before iPhone was a thing
05:16 nfk: *and
05:17 nfk: well, actualy probably 2 phones but still the point stands, there's no other true GNU/Linux even now and Ubuntu is not GNU/Linux, it's just Ubuntu and a failure
05:17 RSpliet: nfk: there's no need to be hostile towards me
05:17 RSpliet: I know the S60, technologically a nice device but didn't catch on in the market
05:18 nfk: muahahaha
05:18 nfk: S60 stands for Symbian 60
05:18 nfk: it's an OS
05:18 nfk: not a device
05:18 nfk: you sure know your stuff
05:18 RSpliet: then I am confused with the N900
05:18 nfk: which ran Debian
05:20 RSpliet: anyway, technological advantage doesn't mean a business advantage these days, my point stays valid
05:20 nfk: nokai went down tue repeated retarded decisions by management
05:20 nfk: much like greece right now
05:20 nfk: *due
05:21 nfk: given their Linux background it should not have been impossible to for Android or keep on working on Debian based phones
05:22 nfk: instead management sold the company to ms for basically their own good
05:22 nfk: *for them to
05:22 nfk: +fork
05:23 RSpliet: in hindseight, Android was probably their best bet indeed because it had the one thing their platforms didn't have (a royally filled app-store)
05:23 nfk: also despite all the fearmongering you could buy a lower end S40 device just last year
05:24 RSpliet: oh yes, but not a lot of people did; sales were declining rapidly in EU/US at least since iPhone was released
05:25 nfk: and i think S60 was selling like strawberry icecream in africa a year or two ago as well so the company would certainly had the money to keep going and come up with their answer to smartphones instead they just gave up and sold out to ms by installing a cretin so stupid that even ms does not want him around
05:25 nfk: yes, elop was fired from ms before being hired by nokia and again let go this year
05:26 nfk: he's one of those managers that's good for only lowering company's value before buyout
05:26 RSpliet: nfk: Are you sure Elop wasn't used as a trojan to reel in Nokia?
05:26 nfk: no, he was used to make Nokia cheaper
05:26 RSpliet: or... their phone division
05:26 RSpliet: same effect
05:26 nfk: which is why MS fired him twice - they don't want to get themselves bled
05:26 RSpliet: but right, irrelevant speculation
05:27 nfk: it's pretty much a fact that elop is good only for that
05:28 RSpliet: ok
05:28 RSpliet: good thing AMD didn't hire him then
05:28 nfk: yet
05:28 nfk: besides amd has already gone lower than nokia, i suspect
05:29 RSpliet: depends on the business unit you consider; the company on the whole isn't doing well, but their GPU division can't be that bad
05:29 nfk: before installing elop nokia was worth at least for times more than amd right now
05:29 RSpliet: Nokia still is, don't forget they do more than just phones
05:29 nfk: you clearly did not even read the link
05:30 RSpliet: I read the speculation yesterday; not interested in the details
05:30 nfk: you clearly missed that am is valued at 1.x bn
05:30 nfk: *amd
05:30 nfk: even nokia was worth around 2 bn when ms bought it, from the top of my head
05:31 nfk: and they didn't buy the entire nokia just their mobile division with restrictiosn on the remainder
05:31 nfk: also i think they got a huge chunk of Nokia IP which itself was worth billions
05:33 RSpliet: I have too little context to compare these two figures
05:34 nfk: in fact, amd is worth so little someone should recommend EC to buy it
05:36 nfk: certainly a much better way to spend money than on greece
06:50 mogorva: if I'm reading this correctly, could it be that the game fails to start because GL_ATI_shader_texture_lod is not implemented in mesa? http://pastebin.com/GnfBqHVJ
07:01 glennk: mogorva, sounds like the game has typo:ed GL_ARB_shader_texture_lod
07:03 mogorva: glennk: hmm, it starts fine with the binary drivers (340.76)
07:04 glennk: you'd be surprised the stuff the binary drivers let through...
07:04 buhman: skeggsb: I suppose hack-gk106m doesn't work on gk107 ;p
07:06 mogorva: glennk: how do you know it is a typo?
07:07 glennk: the ATI one isn't in the registry database of extensions
07:16 xexaxo: glennk: iirc there has been a case where an extension has disappeared from the database ;-)
07:17 Karlton: mogorva: what mesa version do you have?
07:17 xexaxo: glennk: EGL_NOK_swap_region for example
07:18 mogorva: Karlton: current git, here's my glxinfo: http://pastebin.com/FvvTL4cT
07:18 glennk: xexaxo, was that ever a final extension?
07:18 xexaxo: glennk: yes it was. seemingly there was some problems with it, but I don't recall the details.
07:19 mogorva: the game in question: http://www.gog.com/game/the_chronicles_of_riddick_assault_on_dark_athena
07:20 glennk: xexaxo, well, probably because it was replaced by EGL_NOK_swap_region2 once they realized the original version was pretty much useless?
07:21 xexaxo: glennk: perhaps. I'm just saying that published extensions has been known to disappear from the database :-P
07:21 xexaxo: as to why... that's another story
10:29 imirkin: mogorva: i don't see blob drivers exposing any such extension either: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#v=Vendor&p=compat
10:30 imirkin: mogorva: this of course doesn't mean that the blob compiler won't accept something like that
10:33 mogorva: i'll reboot with the binary driver installed and check what glxinfo show. or the game simply dies on something else with mesa. I receive a cryptic error message when starting the game: CRenderContextGL::GLSL_LoadSrc
10:33 imirkin: well it can't load the glsl
10:33 imirkin: so that makes sense
10:34 imirkin: according to https://bugs.freedesktop.org/show_bug.cgi?id=29537, it just enables the *Lod functions in fragment shaders
10:34 imirkin: which is one of the things that ARB_shader_texture_lod also does
10:35 imirkin: it's easy enough to teach the parser about such matters
10:38 mogorva: is there a way to trick the app use ARB_shader_texture_lod instead?
10:38 imirkin: mogorva: http://hastebin.com/exavujolod.coffee -- not even compile-tested
10:38 imirkin: er yeah, doing some sort of alias when parsing the ext would be even smarter
10:41 imirkin: mogorva: something like that http://hastebin.com/enuxerodef.diff
10:42 imirkin: mogorva: unrelatedly, the only outstanding bug you've filed is the civ5 one right?
10:42 imirkin: i seem to recall you've brought up more issues than that, but as i probably promised before, i've long forgotten about them
10:44 mogorva: there's is the issue with games crashing, reported in 91118, mesa-core
10:45 imirkin: oh right
10:45 imirkin: but there are patches
10:45 mogorva: are you planning to switch back to your other gfx card yet?
10:45 imirkin: and i pushed a piglit test which crashes, so we won't forget
10:45 imirkin: i plugged in the GT215 last night... until some catastrophy happens, it'll stay in my system
10:45 imirkin: (i still use the GF108 as the primary though)
10:46 mogorva: may i bother you with more bugs I found so far?
10:46 imirkin: please do. but don't forget to file them.
10:47 imirkin: you're a lot faster at finding bugs than i am at fixing them
10:47 imirkin: and as you've probably noticed, having a trace that exhibits the issue greatly simplifies the process
10:48 mogorva: mesa doesn't compile with your patch: builtin_functions.cpp: In function 'bool lod_exists_in_stage(const _mesa_glsl_parse_state*)':
10:48 mogorva: builtin_functions.cpp:171:18: error: 'const struct _mesa_glsl_parse_state' has no member named 'ATI_shader_texture_lod'
10:48 mogorva: state->ATI_shader_texture_lod;
10:49 mogorva: i mean this patch: http://hastebin.com/exavujolod.coffee
10:49 imirkin: oh that shoul dhave been lod_eanble
10:49 imirkin: lod_enable
11:12 mogorva: imirkin: none of the patches fixes the problem, I'm getting the same error message on game start, it must be something else then...
11:14 mogorva: ATI_shader_texture_lod is not even listed in glxinfo after the patch
11:15 imirkin: well, at the very least the "warning: extension `GL_ATI_shader_texture_lod' unsupported in vertex shader" should be gone
11:15 imirkin: if you make an apitrace, that should show the shader source
11:18 imirkin: i think that stupid GL_ATI_shader_texture_lod ext wants diff functions... based on the errors it wants a 3-arg texture2D() call instead of using texture2DLod
11:19 mogorva: the trace file contains only a single frame (10490 calls), and under the <Shaders> tab I have: 'No bound shaders'
11:19 imirkin: can you look at 'apitrace dump' output?
11:19 jakllsch: imirkin: http://pastebin.ca/3041474 the dmesg of the machine that won't load nouveau
11:20 jakllsch: good luck gleaning any useful information from it
11:20 imirkin: jakllsch: no signs of life from nouveau, interesting
11:21 imirkin: jakllsch: that means that either (a) you don't have module autoloading, (b) you've blacklisted nouveau. i'm going towards the latter.
11:21 imirkin: jakllsch: grep -r nouveau /etc/modprobe*
11:21 jakllsch: nothing
11:21 imirkin: and can i see dmesg after you 'modprobe nouveau' ?
11:21 imirkin: (or does it not print anything new?)
11:21 jakllsch: # modprobe nouveau
11:21 jakllsch: modprobe: ERROR: could not insert 'nouveau': No such device
11:22 jakllsch: nothing new in dmesg
11:22 imirkin: right, but is there anything new in dmesg?
11:22 imirkin: gr
11:22 imirkin: that's extremely odd. congratulations ;)
11:22 jakllsch: heh
11:22 jakllsch: imirkin: i should note ... the machine is a Sun Ultra 40 M2 ... running a port of coreboot for firmware. when it runs the Sun firmware it works
11:23 imirkin: jakllsch: can you pastebin 'lspci -vvnn -d 10de:'
11:23 jakllsch: that'll get a lot of the chipset, but sure
11:23 imirkin: well
11:23 imirkin: i just want the video card
11:23 mogorva: in the dumped trace I found: //Might need to fix this in case pxlfmt says it's unsupported
11:23 mogorva: #extension GL_ARB_draw_buffers : enable
11:23 mogorva: #extension GL_ATI_shader_texture_lod : enable
11:24 imirkin: but there's no way to restrict on class in lspci that i remember
11:24 imirkin: mogorva: yeah, but i want the rest of the shader :)
11:25 jakllsch: imirkin: http://pastebin.ca/index.php lspci -vvnn of the only video card
11:25 mogorva: here's the full dumped trace: http://pastebin.com/XEYDR5zF
11:25 imirkin: mogorva: just another random attempt: http://hastebin.com/ararafinax.md
11:25 jakllsch: d'oh
11:25 jakllsch: http://pastebin.ca/3041478
11:25 mogorva: on top of the previous patches?
11:26 imirkin: er wait. no. don't use that one.
11:26 imirkin: float4 tex2DBias(sampler2D _tex, float2 _st, float _bias) { return texture2D(_tex, _st, _bias); }
11:27 imirkin: i think that's a EXT_gpu_shader4 thing
11:27 imirkin: it doesn't actually end up using any of the tex2dlod things
11:28 imirkin: but glsl 1.30 adds texture(bias)
11:30 imirkin: and the problem is that it's trying to use *bias* in vs, whereas glsl 1.20 only has it in fs
11:32 imirkin: mogorva: http://hastebin.com/ufekibigug.md -- instead of the other patches
11:33 imirkin: jakllsch: yeah, i got nothing. sorry. sounds like coreboot isn't initializing *something*, but what? no idea.
11:35 imirkin: jakllsch: i'd trace through nouveau init and see where exactly it's bouncing out
11:35 jakllsch: i'll start playing with a custom kernel i guess
11:36 imirkin: it seems like vga is coming up though, at least i see vgaarb messages
11:37 jakllsch: yeah, i've got working vga character cell console
11:47 mogorva: imirkin: your latest patch works!! I can get to the menus but the game seems to hit bug 90887 because the screen is garbled
11:51 imirkin: so... ARB_shader_texture_lod is about adding texture2DLod & co to fragment shaders. i guess ATI_shader_texture_lod is about adding bias (??) to vertex shaders? that doesn't really make a lot of sense =/
11:51 imirkin: bias is on top of an automatically-computed lod... but that can't happen in a vertex shader
12:00 mogorva: hmm..the corrupted menu screen remains even with your patch applied from https://bugs.freedesktop.org/show_bug.cgi?id=90887#c9
12:02 imirkin: trace :)
12:02 mogorva: just a minute
12:03 imirkin: could be that the gpu doesn't take kindly to TXB in the vertex shader
12:03 imirkin: and really it should just get converted to a TXL
12:05 imirkin: also the nv50 backend does some really dodgy stuff for TXB/TXL when the lod/bias argument is non-uniform... but it's unclear to me that it needs to happen in vertex/geometry shaders...
12:05 imirkin: mwk: any idea btw? do we have to do that quadop thing for non-uniform lod/bias outside of fp?
12:08 imirkin: mogorva: oh heh. i just noticed it... the joke is that it doesn't even try to use tex2DBias/texCubeBias. urgh.
12:08 hakzsam_: imirkin, just to be sure, a call to PUSH_KICK flushes the command stream of the GPU to make sure that all commands previously added to a pushbuffer have been executed?
12:09 imirkin: hakzsam_: more like... PUSH_DATA does nothing. PUSH_KICK submits the current pushbuf to the kernel
12:09 imirkin: PUSH_SPACE will also do that if you ask for more space than there is on the current buffer
12:09 hakzsam_: okay, yeah actually we are not sure that all commands have been executed, that's why we use fences sometimes :)
12:12 hakzsam_: as you requested, I added a PUSH_KICK call just after sending the sw mthd which samples the previous batch of counters
12:12 hakzsam_: now I'm thinking about the fence mechanism
12:13 imirkin: hakzsam_: right, but if you wait on a fence, you can be waiting a while if you didn't actually emit the commands
12:13 imirkin: that's why nouveau_fence has all that kick logic built into it
12:13 imirkin: but your hand-made fence didn't
12:14 mogorva: imirkin: here's the trace with your patch applied: https://drive.google.com/open?id=0B-tTbLKBl-tOdVJvQzNlYTRnTXc
12:14 hakzsam_: imirkin, yes, you are right
12:15 imirkin: mogorva: thanks!
12:15 hakzsam_: imirkin, so, you are suggesting to me to remove all my hand-made fence and to use nouveau_fence instead?
12:15 imirkin: hakzsam_: yes
12:15 imirkin: unless there's a reason not to
12:15 imirkin: but i'm not seeing it
12:18 hakzsam_: yeah, not strong reasons I think too, I never tried to use nouveau_fence, but I'm going to take a look
12:20 hakzsam_: basically, I think I'll have to emit a fence in end_query() (just after sending the sw mthd which samples counters) and wait for it in query_result()?
12:22 hakzsam_: nouveau_fence_wait() is for busy waiting, so I need to use nouveau_fence_signalled() in case of wait is false
12:24 mogorva: the game shows the intro videos properly but displays a garbled screen in the menu (even with the software renderer, so it's not bug 90887)
12:30 imirkin: mogorva: ah ok. if with a software renderer it's the same, probably some other issue
12:31 imirkin: mogorva: it's a windows, but it uses opengl directly? a little surprising...
12:31 mogorva: yes , it runs in wine and uses opengl
12:32 imirkin: i wonder if there's a DX backend which actually works :)
12:44 imirkin: mogorva: ok, looks like it also wants the *lod variants in fs as well.
12:50 imirkin: mogorva: oh wow, on nv50 it's *way* garbled. on nvc0 the intro screen has a thing in the top-left corner but otherwise renders ok.
12:50 imirkin: mogorva: with this patch: http://hastebin.com/guqojebebu.md i don't get any more complaints from glsl compiler though
12:52 imirkin: skeggsb: btw, the gddr5 nva3 is an order of magnitude faster than my GF108. and amusingly they boot to *identical* frequency states.
12:53 imirkin: --: core 405 MHz memory 324 MHz for the GF108, --: core 405 MHz shader 810 MHz memory 324 MHz for the GT215
13:12 mogorva: imirkin: the game renders properly in the menus with you latest patch, much appreciated :)
13:12 imirkin: + the one from the PhiMovesPass i assume
13:13 mogorva: no, i didn't apply that one
13:13 imirkin: oh hm. i wonder why it renders so poorly on my gt215 then.
13:13 imirkin: i have a bunch of random patches in my tree, maybe one of them
13:14 imirkin: but it really looks like the type of fail that happens with the messed up phi nodes
13:22 imirkin: mogorva: so with that patch, does the game ~work for you?
13:24 mogorva: yes the game starts and renders properly in the menus, loading times are horrendous and there are some glitches here and there when I get in the game
13:25 imirkin: but it basically works?
13:26 mogorva: yes it does :)
13:26 imirkin: cool
13:26 mogorva: do you need a bug report for the problem?
13:26 mogorva: the startup problem that I had originally
13:27 imirkin: yes please. against Mesa core. feel free to paste the patch i gave you into the bug.
13:27 imirkin: include a trace with the "fixed" mesa version too -- sometimes software will do diff things when compilation of shaders fails
13:28 mogorva: kk, i have to go now but will be back in a few hours
13:28 mogorva: bye
13:28 imirkin: k see ya
13:55 hakzsam_: imirkin, nouveau_fence() seems to work fine http://hastebin.com/atijuvarac
13:55 imirkin: BEGIN_NV04(push, SUBC_SW(0x0700), 1);
13:55 imirkin: PUSH_DATA (push, screen->pm.sequence);
13:55 imirkin: that can go too right?
13:55 imirkin: and the quote pm.sequence thing
13:55 hakzsam_: yeah, I'll remove that sequence
13:56 hakzsam_: and I'll change the sw mthd a bit
13:56 hakzsam_: because now I no longer have to write that sequence at offset 0
13:57 hakzsam_: mmh, but if I remove that sequence, the ring buffer of queries will be useless
13:58 imirkin: oh, well if you need it for non-fence purposes that's fine
13:58 hakzsam_: it is used for both
13:59 hakzsam_: anyways, the while() { usleep() } is not good
14:00 imirkin: well, that's what nouveau_fence_wait does
14:00 imirkin: but it does it in a safer way
14:00 hakzsam_: right
14:02 hakzsam_: in my opnion, I'll have to copy/paste some parts of nouveau_fence_wait() but I don't like the idea
14:03 imirkin: that's why i said just use nouveau_fence_wait
14:03 hakzsam_: imirkin, oh well, I can keep nouveau_fence() and use that sequence number only for the ring buffer, do you agree?
14:03 imirkin: yea
14:04 hakzsam_: :)
14:10 imirkin: or rather, i agree given that you need the sequence. i still haven't quite figured out what your thing does
14:14 hakzsam_: did you take a look at the sw methods interface, btw?
14:14 imirkin: nope
14:14 hakzsam_: http://cgit.freedesktop.org/~hakzsam/nouveau/commit/?h=nouveau_perfmon&id=8ac1d553e06e2f960548927420601218f88a5e1b
14:15 hakzsam_: it might help, but let me explain a bit more
14:16 hakzsam_: basically, I defined 3 sw methods for INIT, SAMPLE and READ actions
14:19 hakzsam_: INIT just writes the configuration of a perfdom object to PCOUNTER and SAMPLE is used to sample all perfdom objects which are tied to the perfmon engine, but READ is a bit different because it writes a sequence number at offset 0 in order to let the userspace to know if the results of all perfdom objects are ready (ie. written to the notifier BO)
14:20 hakzsam_: event if I now use nouveau_fence, that sequence number is still useful to know if results in the ring buffer are too old
14:21 hakzsam_: btw, that ring buffer allows to store 8 queries like the HUD does (to not stall the GPU)
14:22 hakzsam_: imirkin, does my explanation help you? :)
14:30 imirkin: hakzsam_: you overestimate how much i understand what counters are, where they live, and what they're counting
14:31 imirkin: however you've been staring at them for like 2 years, so i trust you :)
14:36 hakzsam_: imirkin, I think mupuf will review that series too, but he seems to be busy by the perfkit one :)
14:36 hakzsam_: I just have to figure out one minor thing and I'll probably submit av2
14:48 hakzsam_: okay, it's ready to go
16:01 jakllsch: how on earth do i get nouveau to print anything anywhere?
16:01 imirkin: jakllsch: printk("asdf\n");
16:02 imirkin: jakllsch: you can also add drm.debug=0xf nouveau.debug=trace which should be quite loud
16:02 jakllsch: right, not DRM_DRIVER_DEBUG?
16:02 jakllsch: er, DEBUG_DRIVER
16:05 imirkin: those macros will respond to the drm.debug setting iirc... i forget
16:06 jakllsch: so, where's the module entry point?
16:07 jakllsch: nouveau_drm.c?
16:07 imirkin: yep
16:08 imirkin: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nouveau_drm.c#n1090
16:25 jakllsch: hmmm
16:26 jakllsch: let's see if i can get a panic() in nouveau_drm_init() to work
16:26 jakllsch: because i'm not seeing anything
16:26 imirkin: if that's the case, then i think you're just not loading the module you think you're loading
16:27 jakllsch: is there a way to find out?
16:27 imirkin: sure, 'modinfo nouveau' -- does it print the path you wanted?
16:27 jakllsch: seems to
16:28 imirkin: try doing 'insmod /path/to/nouveau debug=trace'
16:28 jakllsch: insmod: ERROR: could not insert module /lib/modules/3.16.7/kernel/drivers/gpu/drm/nouveau/nouveau.ko: Unknown symbol in module
16:28 imirkin: excellent
16:29 jakllsch: mxm and acpi gunk in dmesg
16:29 imirkin: for i in `echo drm,drm_kms_helper,ttm,fb,backlight,cfbfillrect,cfbimgblt,wmi,video,i2c-algo-bit,cfbcopyarea | sed s/,/ /`; do modprobe $i; done
16:29 imirkin: er crap
16:29 imirkin: for i in `echo drm,drm_kms_helper,ttm,fb,backlight,cfbfillrect,cfbimgblt,wmi,video,i2c-algo-bit,cfbcopyarea | sed 's/,/ /'`; do modprobe $i; done
16:30 jakllsch: modprobe: ERROR: could not insert 'wmi': No such device
16:30 jakllsch: modprobe: ERROR: could not insert 'video': No such device
16:30 imirkin: meh, that's probably fine
16:30 imirkin: now do the insmod
16:31 jakllsch: same missing symbols
16:31 imirkin: hmmmmm
16:32 imirkin: i wonder if you really do need wmi and video then
16:32 imirkin: and that's why modprobe nouveau fails -- it fails to load its deps
16:32 imirkin: wmi sounds oddly related to mxm, but i don't remember how
16:32 imirkin: and i could def see a dep on video...
16:32 imirkin: perhaps those are built-in and you didn't rebuild the module?
16:33 jakllsch: let me make modules_install install and reboot
16:34 jakllsch: but it appears they are not builtins
16:34 jakllsch: remember, this system has no ACPI
16:34 jakllsch: but it's not like i should need acpi tables to use nouveau either
16:36 imirkin: what your system has is irrelevant... what's relevant is what was built and how it was compiled
16:37 imirkin: if at build time you told nouveau to call into the wmi stuff, it'll try to do it.
16:37 imirkin: and in order to try, it has to have the other module there
16:37 imirkin: and if the other module refuses to load, then by extension, so does nouveau
16:37 Karlton: this is why I build my kernel as a single monolithic binary :)
16:37 imirkin: the other module certainly *shouldnt* refuse to load just because you don't have acpi though
16:38 imirkin: but who knows, perhaps it does
16:43 jakllsch: well let's try CONFIG_ACPI_WMI=y and CONFIG_MXM_WMI=y
16:44 imirkin: i'd actually do =n
16:44 imirkin: you don't need them... they're for funky gpu's in even funkier laptops
16:45 jakllsch: true, but either way i should find out if they're at fault
16:45 jakllsch: and i already started the rebuild
16:45 imirkin: hehe
16:45 imirkin: yeah, it doesn't really matter either way
16:47 imirkin: oh, and video is ACPI_VIDEO
16:47 imirkin: [and you might want to nuke the panic you put in... heh.]
16:49 jakllsch: heh, i just remembered
17:03 imirkin: jakllsch: just glanced at acpi/video.c -- looks like it *should* load even in the absence of acpi...
17:04 imirkin: unless acpi_bus_register_driver fails... that'd suck
17:04 jakllsch: for all i know i'm looking at an already-fixed bug, i'm testing 3.16.7
17:05 jakllsch: (vanilla with a config based on the debian jessie config)
17:05 imirkin: could be
17:05 imirkin: but having ACPI=y and no acpi without noacpi is uncommon.
17:05 imirkin: isn't there a 3.16.infinity by now?
17:06 jakllsch: apparently 3.16 wasn't blessed with long-term upstream support
17:06 imirkin: oh hm. apparently not.
17:06 imirkin: i thought it was, for some reason. maybe just debian/canonical
17:09 jakllsch: the plan is to implement acpi for this board in coreboot eventually anyway, but i sort of want to be able gloat over modular kernels sucking. :-)
17:09 Karlton: "Canonical provides extended support until April 2016" I don't know why they maintain an EOL kernel though
17:09 imirkin: anyone around on a GT200+ tesla or any fermi with nvidia blob drivers? if so, i'm looking for a trace of piglit's bin/arb_transform_feedback2-draw-auto
17:10 imirkin: [and by trace, i mean mmt trace]
17:10 jakllsch: Karlton: heh, i wonder what happens for jessie then
17:16 imirkin: jakllsch: modular makes sense for distros. no idea why anyone in their right mind would build a modular kernel for themselves though.
17:16 imirkin: [same comment with s/modular/initrd/ btw]
17:20 jakllsch: well, looks like i got it loaded. and now it's spewing
17:21 imirkin: yay!
17:22 jakllsch: *sigh*
17:22 jakllsch: i should probably just get in the habit of building my own monolithic kernels :-)
17:25 jakllsch: should not have set debug level default to 7
20:17 imirkin: jakllsch: even having the max debug level, not the default, higher than the trace level, is a really bad idea
20:17 imirkin: every mmio write is instrumented at the highest level
20:17 imirkin: and there are a lot of those :)
22:47 imirkin: has anyone ever considered using llvm OpenCL -> PTX and then using ptxas to generate a binary as a shortcut to making opencl work on nouveau?
23:17 imirkin: mogorva: patch for civ5 available... for some reason replaying your trace hangs for me somewhere in glXSwapBuffers or whatever, but the one screen it appears to display is correct
23:19 mogorva: imirkin: thanks, i'll give it a try
23:49 mupuf: gnurou: hey, did you test that configure really checked for the drm version in your mesa patch?
23:49 mupuf: I just can't seem to get it to check the version
23:49 mupuf: will push the patch later, when it is fixed
23:51 mupuf: xexaxo: that may be of interest to you too
23:52 gnurou: mupuf: honestly? I haven't >_<
23:52 gnurou: mupuf: looking at it, sorry about that
23:52 mupuf: well, don't be sorry, you just followed the example
23:53 mupuf: autotools is just like black magic
23:53 mupuf:does not trust it, hence why he tested
23:53 gnurou: yeah, I had hoped I could cross-compile Mesa with scons, but it seems like autotools is still required for that
23:54 gnurou:avoids autotools like plague
23:54 mupuf: hehe, I have no choice anymore :D
23:55 gnurou: I like CMake personally, but it also has its flaws...
23:55 gnurou: that's one of the biggest missing parts of the free ecosystem: a reliable, sound build system
23:55 gnurou: (the other one being the lack of a good modern email client)
23:56 mupuf: oh, there is no reliable, sound build system at all. As far as I know
23:56 gnurou: good point :)
23:57 mupuf: cmake started with a good idea (declarative) but it did not go there all the way
23:57 mupuf: looking forward to studying QBS
23:57 imirkin: flaws like... it's not autotools. autotools is the standard. it works *really* well... anytime i try to use a project with cmake, it's a disaster
23:57 airlied: yeah never seen one in any world, most closed src people still use open source build systems
23:57 airlied: or massive MSVC project files
23:57 mupuf: imirkin: autotools are fragile and very easy to screw up
23:58 imirkin: not to say that cmake is intrinsically a disaster, but it just never works. various things that i need for it to be usable appear to be afterthoughts.
23:58 gnurou:did not intend to start a huge offtopic discussion
23:58 mupuf: recompiling mesa with --enable-debug does not even recompile the entire project even though it adds -DDEBUG to all the compilation flags
23:58 imirkin: mupuf: yeah, recompilation is a bitch no matter where you go
23:58 mupuf: that, to me, is a flawed build system. CMake gets it right straight away
23:59 gnurou: SCons was quite good last time I checked (~10 years ago), is there a reason why it has not taken over in Mesa?
23:59 mupuf: piglit has a weird cmakelist.txt, but hey, it has thousands of binaries, so it is ok
23:59 imirkin: gnurou: because it's not autotools :)
23:59 mupuf: gnurou: just as painful in my opinion
23:59 mupuf: imirkin: oh, and autotools are not portable to non-unix systems
23:59 imirkin: out-of-tree builds as well as in-tree, cross-compilation, etc
23:59 mupuf: anyway, got to go :D Sorry for releasing a hairy troll!
23:59 imirkin: mupuf: see, i've heard that a *lot*, but i have no idea what that means. afaik it's plenty portable.