04:30robclark: skeggsb, imirkin, btw, re: bogus-vram patch, I don't suppose there is some VERSION register or some other register w/ well known value that you could try to read and see if you get a sane value?
04:58skeggsb: robclark: one of the bugs where we have it *should* be solved now, caused by reading the mc registers before they're initialised
04:58skeggsb: robclark: the other, not yet diagnosed
04:59skeggsb: robclark: whether or not you read an error code or real data is very fine-grained, and not a whole-gpu thing
05:07robclark: ahh.. well if you *did* go the route of trying to decide if what you read is valid, picking some reg in a particular block that you should get a known value seems a saner approach, if possible..
05:56buhman: ooh, things need testing?
07:26pmoreau: Some more documentation!
07:55jack_desktop: Hello I was hoping someone here could help me with something, that being the command /sys/class/drm/card0/device/pstate
07:55jack_desktop: echo 0f > /sys/class/drm/card0/device/pstate doesn't seem to save/work
07:56jack_desktop: And I can't work out how to get it to stick so it is always enabled at bootup
07:57imirkin: jack_desktop: nouveau.config=NvClkMode=15
07:57jack_desktop: Thanks imirkin, really appreciated!
07:57jack_desktop: Wait one last question where do I add that?
07:58imirkin: kernel cmdline
07:58jack_desktop: Ahh thanks!
07:58imirkin: [presumably you already have nouveau.pstate=1 there]
07:58jack_desktop: Also should I be worried about this output? [ 281.541072] nouveau E[ CLK][0000:01:00.0] failed to raise voltage: -22
07:58jack_desktop: [ 281.541078] nouveau E[ CLK][0000:01:00.0] error setting pstate 3: -22
07:58jack_desktop: And yes I already have nouveau.pstate=1
07:59imirkin: that means the pstate transition is failing
08:00jack_desktop: Okay, I have pstate set in GRUB_CMDLINE_LINUX_DEFAULT
08:00jack_desktop: Is that correct?
08:00jack_desktop: I also have quiet splash in there...
08:00imirkin: sounds like grub2 stuff, dunno how to configure it. perhaps get help on that from a distro chan
08:01jack_desktop: Okay well thanks again, I will reboot and see if that fixed it
08:05jack_desktop: Thank you, thank you, thank you imirkin, it works perfectly!
08:06jack_desktop: Someone really needs to post that as a proper guide somewhere
08:06jack_desktop: As that took a lot of effort to get to this stage
08:07imirkin: go for it
08:08jack_desktop: Ha I don't have a website or anything, so =\
08:08jack_desktop: Will keep it in mind though and post it as a gist somewhere as well
08:09jack_desktop: How can I check the clock etc speed is correct?
08:09jack_desktop: I know of lshw -c video
08:09jack_desktop: But that seems to report incorrectly
08:11jack_desktop: cat /sys/class/drm/card0/device/pstate seems to report the clock speed etc.
08:12jack_desktop: But I wanted a second verification oh well guess I won't get it
08:12jack_desktop: Everything seems to be running smoothly now so I'm happy
08:12jack_desktop: Once again thanks imirkin!
09:03imirkin: pmoreau: yeah. sadly no --make-it-work flag. but that "lmem" flag makes a lot more sense now at least.
09:04imirkin: as well as the gmem one
09:16xexaxo: tobijk: </offtopic> did you get to the bottom of that funny libdrm regression ?
09:31pq: what was the funny libdrm regression exactly?
09:31imirkin: something about xf86-video-intel not working when compiled against libdrm-2.4.61 for some odd reason
09:34imirkin: not sure if it's been reported to ickle & co
09:35tobijk: xexaxo: i did a bisect, thats as far as i got till now
09:36tobijk: bug for it: https://bugs.freedesktop.org/show_bug.cgi?id=90403
10:26xexaxo: hmm using an in-house drm_i915_gem_mmap (i.e. keeping it to v1). won't memset(&foo, 0, sizeof(foo)) work just fine there ?
10:27xexaxo: although the drm_i915_gem_get_tiling change will likely cause some explosions the next time it's extended.
10:31xexaxo: actually the intel ddx has a scaringly large list of local_*(s)
11:05moochmcgee: quick question: does anybody know what crtc register 38h is?
11:05moochmcgee: i'm writing a riva 128 emulator
11:05moochmcgee: and this register is only written in quick succession with the values 0, 3, 5, and 7.
11:06moochmcgee: at least, in my app that tries to use VESA 1.0 modes
11:07moochmcgee: so far, i have really basic VESA stuff working
11:10imirkin_: riva128 = nv1 or nv3?
11:11moochmcgee: nv1 is a whole nother beast
11:12imirkin_: right, i knew they were diff beasts, just didn't remember which was which ;)
11:12moochmcgee: aight, sorry
11:12imirkin_: iirc mwk had a software impl of nv3
11:13imirkin_: hmmmm... maybe i'm just thinking of its pgraph for which there's a hwtest in envytools
11:18imirkin_: moochmcgee: best i can do is this: https://github.com/envytools/envytools/blob/master/rnndb/display/nv_vga.xml#L142
11:19imirkin_: and also nv3_pcrtc.xml in the same dir
11:20imirkin_: or perhaps https://github.com/envytools/envytools/blob/master/rnndb/display/nv_vga.xml#L344
11:31moochmcgee: i've looked in the vga file
11:32moochmcgee: one of my friends theorized it could have something to do with spi
11:32moochmcgee: but i don't think the nv3 does that
11:33moochmcgee: he also thought that it might have to do with the monitor's EDID
11:33moochmcgee: btw, there are lots of registers that aren't documented in that rnndb file
11:37hakzsam: imirkin_, why pipeline statistics queries use 64 bits on nvc0, and not on nv50? is that expected?
11:37hakzsam: btw, those queries don't work on my NVA8 but I have a patch which seems to fix the issue
11:38hakzsam: just wondering why they don't use 64 bits...
11:38imirkin_: hakzsam: someone claimed they worked. and yes, they should be marked as 64-bit, but i followed the code and it seemed like it wouldn't matter in the end
11:38imirkin_: hakzsam: and since i was too lazy to test on my own hw, i never sent a patch
11:38hakzsam: yeah, I saw the Tested-by
11:39hakzsam: imirkin_, I'll do
11:41hakzsam: tobijk, btw, do we have piglit tests to test GL_ARB_conditional_render_inverted?
11:42imirkin_: tests exist, i forget if they got pushed or not
11:42hakzsam: okay, I'm going to check
11:43imirkin_: hm, doesn't look like they were ever pushed
12:29tobijk: hakzsam: i guess i have them somewhere, let me see
12:29tobijk: and yeah they got never pushed
12:32tobijk: hakzsam: they still exist, i have to rebase them
12:35imirkin_: for some reason i thought that airlied rage-pushed them
12:35tobijk: nah he rage-pushed soe cull_distance bits :D
12:35tobijk: to piglit
12:35imirkin_: ah heh
12:36tobijk: i guess i was tripping on his nerves a bit too much :/
12:36imirkin_: more like "got sick of having no tests, nobody was reviewing, didn't feel like doing it either, so wtvr, just push, it's piglit"
12:50robclark: hm, for kernel traces, is drm.debug enough or is there more.. I remember nouveau had it's own tracing stuff..
12:52imirkin_: robclark: are you having issues with nouveau?
12:52robclark: helping someone else debug laptop that explodes..
12:53robclark: when nouveau loads
12:53imirkin_: what kernel?
12:53imirkin_: if it's 4.1-rc, and a semi-recent gpu, there was a *nasty* regression introduced
12:53imirkin_: that ben just fixed yesterday
12:53robclark: hmm, looks like maybe I want CONFIG_NOUVEAU_DEBUGtoo?
12:53imirkin_: it's set to trace-level by default
12:53tobijk: imirkin_: was that faild to idle?
12:53robclark: would symptoms be a stream of SCHED_ERROR?
12:53imirkin_: and you never need to go beyond trace with *exceedingly* rare exceptions
12:54imirkin_: could be... i don't know
12:54imirkin_: one of the class id's was wrong
12:54imirkin_: which the hardware needs to be correct
12:54imirkin_: is it 4.1-rc? or earlier?
12:54tobijk: ke, i saw those the last 2 days while rebooting :/
12:54robclark: I think it is 4.0 atm..
12:55hakzsam: imirkin_, I have a waffle error while running arb_pipeline_statistics_query tests http://hastebin.com/wigugawino.sm , other tests like vbo-bufferdata works fien
12:55imirkin_: tobijk: failed to idle is just a generic "this context got stuck" error
12:55imirkin_: hakzsam: are you on maxwell?
12:55hakzsam: imirkin_, no, nva8
12:55robclark: imirkin, ben's fix on mainline yet, or ?
12:55imirkin_: weird... dunno. iirc there were some fixes
12:56imirkin_: robclark: no, just in his repo
12:56imirkin_: robclark: but the commit that introduced it came into 4.1, so... not it
12:56imirkin_: robclark: what hardware is this?
12:56imirkin_: (lspci -nn -d 10de: should give you a GFxxx GKxxx or GMxxx code)
12:56robclark: maxwell I think.. I'm just helping the guy get kernel traces out of this first, then was going to go from there :-P
12:57imirkin_: oh, he fixed some of those yesterday too... if it's a maxwell without display
12:57imirkin_: http://cgit.freedesktop.org/~darktama/nouveau -- the top 2 commits
12:57imirkin_: robclark: a plain dmesg should be sufficient to diagnose this
12:58imirkin_: i bet it'll have some difficult-to-believe quantity of vram
12:58imirkin_: (e.g. negative. or multiple petabytes.)
12:59robclark: imirkin, well, first attempt was an infinite stream of SCHED_ERROR ;-)
12:59imirkin_: robclark: presumably it didn't *start* that way
13:00hakzsam: imirkin_, btw, I get a skip but no errors on NVD9, is that expected?
13:00robclark: yeah, yeah.. we are doing it again and trying to dump it all to file before kernel trace buffer overflows ;-)
13:00robclark: although maybe I should just add a ratelimit around that error msg in code
13:01imirkin_: hakzsam: for what? ARB_pipeline_statistics? no. but it's only there in recent mesa versions
13:01imirkin_: like... git probably
13:01imirkin_: robclark: yeah, rate limits in intr's are all the rage :p
13:01imirkin_: just sleep in the intr a little longer, all your problems will disappear :)
13:02hakzsam: imirkin_, okay, same waffle errors with mesa git on NVD9
13:02imirkin_: that's a little worrying =/
13:04robclark: imirkin, ratelimit won't sleep, it will drop..
13:05imirkin_: yeah... but there's a lot of intr's
13:05imirkin_: anyways, getting the start of dmesg would be key
13:06imirkin_: ime, netconsole works gret
13:06robclark: fwiw, it is GM107
13:06robclark: we managed to get trace..
13:06robclark: (just modprobe.blacklist it, and ssh in after things are up and modprobe it then..)
13:06imirkin_: does it have the ridiculous vram as i predicted?
13:07robclark: vram looks ok.. 1GiG..
13:07robclark: but, GART: 1048576 MiB
13:07imirkin_: that's normal
13:08imirkin_: is this a primary or secondary gpu?
13:08hakzsam: xexaxo, Hi, does this waffle issue is already know http://hastebin.com/wigugawino.sm ?
13:09imirkin_: hakzsam: most likely somethign on your end... pastebin glxinfo?
13:09hakzsam: paths are correct
13:09robclark: imirkin_, I would assume secondary? http://hastebin.com/raw/vijakazivi
13:13tobijk: who messed with all.py :O
13:13imirkin_: hakzsam: OpenGL version string: 2.1 Mesa 10.7.0-devel (git-51ccdb6)
13:13imirkin_: hakzsam: did you forget --enable-float-textures ?
13:14hakzsam: my bad, yes
13:15robclark: imirkin, skeggsb, I'd recommend something roughly like http://hastebin.com/raw/aveturijam to at least avoid DoS'ing the user when things like this happen
13:16imirkin_: robclark: seems reasonable to me :)
13:16imirkin_: robclark: i think the top 2 patches in ben's tree may help
13:17robclark: I need to actually at least compile test it, but after that I'll send a patch..
13:17robclark: hmm, where actually is ben's tree?
13:18imirkin_: it's a funny out-of-tree situation, but i'm sure you can work out how to port the patches
13:18imirkin_: or you can compile the out-of-tree module by doing "cd drm; make"
13:18imirkin_: [might be a git clone somewhere in there too...]
13:19imirkin_: hakzsam: and it's waffle's bad that it tries to use glXCreateContextWhatever
13:21robclark: ok, that is kinda weird setup..
13:22robclark: imirkin, fyi bentiss is the one with the troublesome laptop ;-)
13:26imirkin_: robclark: yeah, it's weird... everyone but ben thinks so. but ben's the only real contributor, so...
13:27robclark: imirkin, so looking at patches there, http://cgit.freedesktop.org/~darktama/nouveau/patch/?id=cf5c2a749912102055844b51a40b3ef64210afe6 is the one that looks relevant..
13:29imirkin_: robclark: and the previous one
13:30imirkin_: you can't tell that it's relevant, but it is ;)
13:30xexaxo: hakzsam: I take it that after rebuilding mesa things worked out ?
13:31xexaxo: imirkin_: can you elaborate - what is waffle doing wrong there ?
13:32imirkin_: xexaxo: glXCreateContextProfileBlah is only available on GL3
13:32xexaxo: imirkin_: true, and the test requires compat 3.0.
13:32imirkin_: xexaxo: yeah, but waffle calls the function no matter what
13:33imirkin_: so *for that test* it may be fine
13:33imirkin_: but if the test required gl2.1, you still call it
13:33imirkin_: [unless it was fixed recently]
13:34xexaxo: hmm are you sure that the glX function is "available in GL3" ?
13:34imirkin_: iirc idr said so
13:34imirkin_: i tend to trust him in such matters
13:34imirkin_: i could be getting the details mixed up though
13:35xexaxo: me too, just that this is the first time I've heard a platform function (extension) being available in the GL standard.
13:36xexaxo: they tend to keep the two separate. and allow extra functionality in the platform specific ones, if GL X is available.
13:36xexaxo: not the other way around.
13:37imirkin_: GLX_ARB_create_context definitely has some GL3-sounding text
13:37tobijk: hakzsam: rebased just for you ;-) https://git.thm.de/tjkl80/piglit/tree/arb_conditional_render_inverted
13:38tobijk: (not tested after rebase at all)
13:39imirkin_: robclark: er wait. ignore me.
13:39imirkin_: robclark: you have the same issue as...
13:40imirkin_: robclark: bentiss: http://lists.freedesktop.org/archives/nouveau/2015-May/020793.html
13:40xexaxo: "However, 3.0-aware applications are encouraged to use wglCreateContextAttribsARB"
13:40imirkin_: and those patches won't help you because you're already executing the init tables. all those patches do is catch situations where you should be runnign them better
13:40xexaxo: oops, someone forgot to sed through the spec :)
13:41bentiss: imirkin_: yep, the laptop has a 850M
13:41imirkin_: bentiss: if you're able, do a mmiotrace
13:41RSpliet: ... "VIC", is that a salute to the Commodore 64?
13:41imirkin_: RSpliet: nvaf had a VIC too
13:41imirkin_: also falcon-based iirc
13:42imirkin_: video image compositor :)
13:42bentiss: imirkin_: I'll try
13:43imirkin_: bentiss: of the blob drivers, naturally
13:43imirkin_: you don't have to do a lot... something as simple as 'nvidia-smi' should be enough
13:43imirkin_: bentiss: this is a nice guide on how to get that going: https://wiki.ubuntu.com/X/MMIOTracing
13:43bentiss: ok, so I need first to install the blob driver :(
13:43imirkin_: install is a strong word
13:44imirkin_: but you do need to have it around
13:44bentiss:has bad memories of trying to remove it from various systems...
13:44imirkin_: yeah, i never install it
13:44imirkin_: i just extract it, and then adjust LD_LIBRARY_PATH's when i want to use its userspace stuff
13:44robclark:assumes you can do some hack of "installing" it in a chroot or something?
13:44robclark: or that
13:45imirkin_: just be careful running 'make', since it will try to install if you're root
13:45bentiss: ideally, compile the blob, and insmod it
13:45imirkin_: nice little nasty surprise :)
13:45imirkin_: just do sh foo-blob.run -x
13:46imirkin_: that will extract it
13:46imirkin_: you'll have to ldconfig -something, otherwise none of the symlinks will be there
13:46bentiss: imirkin_: the version (beta or not) does not matter I guess
13:46imirkin_: anything that supports your gpu is fine
13:46imirkin_: [and doesn't also crap out on load]
13:46imirkin_: coz we apparently already know how to crap out on load
13:47imirkin_: bentiss: before you spend a bunch of time getting this figured out though, what's your goal?
13:48imirkin_: bentiss: if it's to have "faster" 3d accel, stick with intel
13:48bentiss: imirkin_: it's more "save a lot of people" and also "be able to boot the *** machine without having to blacklist nouveau" :)
13:49robclark: imirkin, it is to have the laptop usable without nomodeset or blacklisting ;-)
13:49bentiss: that's what I said!
13:49robclark: irc race conditions...
13:49imirkin_: k. you can also just not build nouveau ;)
13:49imirkin_: but if you want to help, that's great :)
13:49imirkin_: just wanted to manage expectations a bit
13:50robclark: imirkin, the problem is that distro kernels (for example) tend to enable nouveau ;-)
13:50bentiss:does not have expectations... I already work in the kernel and know what it is
13:50imirkin_: robclark: i don't think i've booted a distro kernel in *quite* some time. last one was probably the RH6 2.0.36 kernel or so
13:51imirkin_: i tend to forget the level of insanity involved :)
13:51robclark: you aren't exactly the end user we are trying to save from tears ;-)
13:51hakzsam: "configure: WARNING: Please consult docs/patents.txt with your lawyer before building Mesa." fun :-)
13:51hakzsam: imirkin_, xexaxo yeah, works fine now
13:51hakzsam: tobijk, thanks, I'll try
13:51imirkin_: [i geuss that's not true... installers tend to use distro kernels.]
13:52hakzsam: imirkin_, arb_pipeline_stats tests don't work with mesa master, I'm going to try with my patch
13:52imirkin_: hakzsam: nva8 or nvd9?
13:53imirkin_: what's the failure mode?
13:54hakzsam: no failure, infinite loop because queries are busy..
13:54xexaxo: imirkin_: I'm still struggling to find anything in the spec on the topic.
13:55xexaxo: do you have a link with the discussion by any chance ?
13:55xexaxo: there is a piece in the spec "The presence of an OpenGL 3.2 or later implementation determines
13:55xexaxo: whether or not GLX_ARB_create_context_profile is required"
13:56xexaxo: although that does not forbid the opposite - i.e. the glX extension is/should not be used with OpenGL <2.1 contexts
13:57xexaxo: not saying that waffle is perfect, just that I'd appreciate some information on what is the correct thing to do.
13:58xexaxo: ... is
13:58imirkin_: xexaxo: yeah. so. the error may be in piglit. i really don't remember.
13:58imirkin_: i do remember that it was trying to do something that i felt was dodgy.
13:58imirkin_: apparently i've gotten the details a bit mixed up though
13:59xexaxo: there was a point (way back) about compat vs core vs which GL version.
13:59imirkin_: no, it's not about that
13:59xexaxo: that one was in piglit, and iirc Chad fixed it.
14:00bentiss: imirkin_: FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'lock_release' -> that's fun to work with blobs!
14:01imirkin_: xexaxo: if (!wcore_config_attrs_version_eq(attrs, 10) && !dpy->ARB_create_context) in src/waffle/glx/glx_config.c
14:01xexaxo: the "Legacy Context Creation" section in the spec (minus the typo) does explicitly encourage people to use the ARB function
14:01imirkin_: that was the dodgy that i remembered
14:01xexaxo: "However, 3.0-aware applications are encouraged to use
14:01xexaxo: wglCreateContextAttribsARB instead of the legacy routines"
14:02imirkin_: and i mistook hakzsam's error for the same issue
14:02xexaxo:takes a look
14:02imirkin_: xexaxo: there's no reason to have that error there
14:03imirkin_: xexaxo: it's a GL3-era extension, which means it's perfectly legitimate to not have it
14:03hakzsam: imirkin_, well, not sure if those tests are correct since they don't report any failure/success mode
14:03imirkin_: hakzsam: run with -auto
14:03imirkin_: otherwise they just put up a window and don't do antyhing
14:03imirkin_: (until you close the window)
14:03xexaxo: iirc there was something funny in the spec about this (I recall reading something similar in the wgl version)
14:03hakzsam: imirkin_, I didn't know, let me test again
14:05imirkin_: bentiss: oops! yeah, dunno what to do about that, i've never gotten that error. i guess you can just update the license to get past it.
14:05imirkin_: bentiss: note that if you insmod, you'll have to manually modprobe drm, and perhpas one other module... modinfo should tell you waht.
14:05tobijk: hakzsam: maybe i rebased all.py wrong
14:06hakzsam: tobijk, nope, works fine with -auto (I didn't try your tests yet)
14:06bentiss: imirkin_: OK
14:06tobijk: ah ok :)
14:06bentiss: imirkin_: I worked around the problem with a suggestion from robclark: change the nvidia license :)
14:06imirkin_: didn't i just suggest it? or he probably did so privately
14:07hakzsam: imirkin_, well, all pipeline_stats tests are okay on my nva8 for both master and with two patches (except *-comp which requires GL_ARB_compute_shader)
14:07imirkin_: hakzsam: right, no compute shader for now :)
14:07xexaxo: imirkin_: actually there is nothing in the spec about that, although the check makes perfect sense.
14:07imirkin_: hakzsam: ok, so the thing *sorta* works... wonder what the HUD is doing
14:07imirkin_: xexaxo: why does the check make sense?
14:08bentiss: imirkin_: Oh, yes, I overlooked your answer (but having robclark on the desk next to me allows some efficient communications from time to time)
14:08xexaxo: if one explicitly requires a version then they _must_ go through the ARB extension.
14:08imirkin_: i have a GL2.1 library, i want a GL2.1 context, i don't have ARB_context_create. what's so wrong with that?
14:08hakzsam: imirkin_, so, I can get your R-b for the series, right?
14:08xexaxo: as the original (legacy) functions do not allow you to choose the version.
14:08xexaxo: the keyword above is explicitly.
14:09imirkin_: xexaxo: how about you just let things work and complain if the version you get is the wrong version
14:09xexaxo: imirkin_: cannot really do that, as waffle does not do anything with the actual context.
14:10imirkin_: xexaxo: but you understand my complaint right?
14:10hakzsam: tobijk, all tests are okay! ;)
14:10xexaxo: imirkin: indeed I do. but my counterargument is - if you ask for a version, and you use the ARB function.
14:10tobijk: at least something works :D
14:11xexaxo: otherwise waffle will be your bookkeeper, which is not meant to
14:11imirkin_: xexaxo: ok, but that's basically like saying "you can't use waffle if you don't have ARB_create_context"
14:11imirkin_: nobody ever requests a 1.0 context
14:11tobijk: imirkin_: you can ragepush now ;-)
14:11hakzsam: imirkin_, btw, pipeline queries only work with my series for the HUD
14:11xexaxo: just no to mention _any_ version and you're swell
14:12xexaxo: the whole notion of saying "I want version ..." implies glXCreateContextAttribsARB
14:13xexaxo: if you go "I want context, and don't care about the version" then you're back to the legacy stuff
14:13imirkin_: xexaxo: ok, but piglit always specifies a version
14:14imirkin_: a *minimum* version
14:14imirkin_: should it be updated to not tell waffle about that
14:14imirkin_: and just check itself?
14:14bentiss: imirkin_: I have the mmiotrace from the load of nvidia.ko, -> http://paste.fedoraproject.org/224462/32242869/
14:14imirkin_: bentiss: you forgot to do things
14:15bentiss:always forget to do things
14:15imirkin_: bentiss: e.g. run nvidia-smi, or something else that causes the driver to actually get the gpu going
14:15xexaxo: maybe that's the better approach - "check the piglit config - legacy version -> do not hint about the version when creating the context, and check the version after that"
14:15bentiss: imirkin_: on it
14:15xexaxo: "using something 3.0 or later, just mention it from the beginning."
14:15imirkin_: that trace just has 2 register reads. (and a write to 0x140? oh, that's interrupt clear)
14:16imirkin_: xexaxo: sounds like a plan to me.
14:16imirkin_: xexaxo: this comes up when someone foolishly tries to use xf86-video-nouveau on maxwell, which has very incorrectly done glamor integration
14:16imirkin_: xexaxo: which ends up without an ARB_create_context
14:16imirkin_: that's how *i* ran into this ;)
14:16xexaxo: imirkin_: although I'm a bit worried about the lack of extension. need to check why it's missing when built without the funny flag
14:17imirkin_: xexaxo: hm?
14:17imirkin_: i traced it down, coz nouveau doesn't enable dri2 when using glamor
14:17imirkin_: and xorg glx exposes that stuff only if dri2 is supported
14:17xexaxo: as in - why does limiting OpenGL to 2.1 prevents libGL from exposing the ARB (GLX) extension.
14:18imirkin_: it doesn't
14:18imirkin_: hakzsam's thing was a different fail, i think
14:19xexaxo: ack. that makes sense - I was scratching my head like a madman here.
14:19imirkin_: his error was that the function was failing
14:19imirkin_: which is also a bit alarming
14:19imirkin_: but different than the error "ha ha, you don't have ARB_context_create, go away"
14:20hakzsam: imirkin_, well, the only difference between arb_pipeline_stats and the HUD is that the latter doesn't block until the result is ready
14:21xexaxo:takes a closer look at the paste
14:22imirkin_: hakzsam: not sure what you mean... it never calls get_query_result with wait=true?
14:22imirkin_: hakzsam: or you mean if it calls with wait=false and the thing returns false, it never retries?
14:23hakzsam: it will retry, but the ring buffer will be full after N queries, it's something like a deadlock
14:25imirkin_: does it run over itself? oh, for 64-bit queries i don't leave room for the sequence number?
14:27tobijk: increase the query size yet again?
14:29hakzsam: imirkin_, the sequence number is always 0 because when all queries are busy, the HUD destroys the last query and create a new one...
14:29hakzsam: tobijk, nope, the ring buffer is large enough, and this is not related to its size
14:30tobijk: noted :)
14:32bentiss: imirkin_: http://people.freedesktop.org/~tissoire/mmiotrace_850M.log -> 27 MB
14:32imirkin_: bentiss: xz -9
14:32hakzsam: imirkin_, when all queries are busy (ie. get_query_result() returns false), there is a dead lock in the HUD, but this is expected :)
14:32imirkin_: and it'll become like 10 bytes
14:32imirkin_: bentiss: also can you throw GM107 somewhere in the filename?
14:32bentiss: imirkin_: I can do that
14:32imirkin_: bentiss: nvidia are not so kind as to provide a unique marketing name -> chip mapping
14:33imirkin_: hakzsam: so... what does this have to do with 32- or 64-bit queries?
14:33imirkin_: i think the connection is that the 32-bit queries all cause a sequence id to get written
14:34imirkin_: whereas the 64-bit ones don't
14:35hakzsam: yes, the sequence is only used for 32-bits queries
14:35bentiss: imirkin_: http://people.freedesktop.org/~tissoire/mmiotrace_850M_GM107-nvidia-smi.log.xz -> 1.5 MB, better!
14:35imirkin_: bentiss: awesome! skeggsb --^
14:36bentiss: oh, if it was all for that, he might already have one :)
14:36hakzsam: imirkin_, so, without a fence we can't know when the query is ready...
14:36imirkin_: hakzsam: ok, that makes a lot more sense. make sure to explain stuff in the changelogs ;)
14:37hakzsam: sure :)
14:38imirkin_: bentiss: yeah sorry. i'm not an actually useful person for these things.
14:38imirkin_: but hopefully this should help him figure out which bit we're not writing
14:40bentiss: imirkin_: no worries, I am prettry sure he might have forgotten where the actual file was given that we tried to enable the laptop few month ago
14:55hakzsam: imirkin_, forgot the v2, sorry...
14:57tobijk: hakzsam: btw, is there some hardware spec forcing us to do that instead of writing a sq_no?
14:58hakzsam: no ideas
14:58imirkin_: tobijk: probably not, but wtvr
14:58imirkin_: tobijk: how do you think the fence thing works ;)
14:58tobijk: yeah well...
15:00tobijk: i'm happy with that patch
15:04hakzsam: I was trying to make the HUD displays floats instead of always u64 when I found that issue
15:07hakzsam: imirkin_, sure, they could be a bit more specific. I'll make the changes tomorrow, time to sleep now