04:53 pmoreau: imirkin: I think I have an idea where the troublesome r0 came from with no instruction attached: it could be the r0 that gets registered by some pass in order to keep it available if needed by the program, since it contains threads id information.
04:54 pmoreau: But I haven't checked that theory out. Just got it this morning and thought it is not completely crazy.
05:21 Tanure: Hi, I have NVIDIA Corporation GM204 [GeForce GTX 970] , and I got this --> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
05:22 RSpliet: Tanure: that's correct
05:22 Tanure: I would like to use my i915 gpu
05:22 Tanure: so, it's like the i915 do all the math, and output in nvidia hdmi
05:22 Tanure: it's possible ?
05:22 RSpliet: okay, so what you're looking for is a "Reverse prime" set-up
05:23 Tanure: will forward the i915 to hdmi in nvidia?
05:24 RSpliet: see http://nouveau.freedesktop.org/wiki/Optimus/
05:25 Tanure: ?
05:25 Tanure: my nvidia needs to be working for this to work
05:26 RSpliet: read the "using outputs on discrete GPU" bit
05:27 RSpliet: I don't have such a set-up myself, so can't help you further with it, but what you want is, as I said, "reverse prime"
05:29 Tanure: If I do this, my OpenGL renderer string will be intel right ?
05:29 Tanure: Will be better at the end , right ?
05:30 Tanure: I'm staring to work with wayland, but this a too slow, and I think this Gallium problem
05:31 RSpliet: it will do whatever you configure it to do, just read the page in full
05:41 sooda_: skeggsb: i guess flush_work() shouldn't be called from the work thread itself? i'm playing around and noticed that gk104_fifo_recover_work() calls nvkm_subdev_fini() which goes to gk104_fifo_fini() that then does flush_work(&fifo->fault). surprise, deadlock. :P
05:43 karolherbst: mupuf: in daemon32s vbios the unk5c table values "0: { unk11 30, 40.00 °C => 960 rpm } 2: { unk13 75, 90.00 °C => 3600 rpm }"corelate with the fan min/max values from the Temperature table "id = 0x22, data = 0x4b1e -- fan_min = 30, fan_max = 75"
05:43 karolherbst: so maybe the unk are indeed the fan duty values
05:46 karolherbst: and unk0e and unk10 in the FAN table are related to that values then
05:47 karolherbst: like the fan operation range
05:49 karolherbst: "unk0e: 960, unk10: 3600"
05:50 Tanure: Hi, I tried the page : http://nouveau.freedesktop.org/wiki/Optimus/
05:50 Tanure: but nothing works
05:50 Tanure: Providers: number : 2 Provider 0: id: 0x94 cap: 0x3, Source Output, Sink Output crtcs: 4 outputs: 5 associated providers: 0 name:modesetting Provider 1: id: 0x4a cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 8 associated providers: 0 name:Intel
06:05 Tanure: xrandr --setprovideroutputsource nouveau Intel
06:05 Tanure: reboots my KDE
06:05 Tanure: but my glxinfo | grep "OpenGL vendor string" OpenGL vendor string: VMware, Inc.
06:06 Tanure: keeps at vmware
06:15 karolherbst: tanure: a plain glxinfo should give you intel
06:15 karolherbst: does it?
06:15 karolherbst: if not, you have to fix your intel side first
06:16 tanure: well, I think that my intel side is ok
06:16 karolherbst: you think or you know?
06:16 karolherbst: if you just type in the command "glxinfo" without DRI_PRIME or anything
06:16 karolherbst: it should give you the intel vendor string
06:16 tanure: for me, my nvidia it's not supported and fallback to gallium
06:16 tanure: nope
06:16 karolherbst: then you messed up your intel side
06:17 tanure: OpenGL vendor string: VMware, Inc.
06:17 tanure: OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
06:17 karolherbst: glxinfo should _never_ print nouveau
06:17 karolherbst: only if you select your nvidia gpu through DRI_PRIME
06:17 tanure: ok but , nouveau > intel > gallium
06:18 karolherbst: no
06:18 karolherbst: intel > everything
06:18 karolherbst: that's the deal with hybrig gpu setups
06:18 karolherbst: intel rules everything
06:18 karolherbst: when intel is messed up, nouveau won't work either
06:19 karolherbst: your desktop has to run on the intel gpu
06:19 karolherbst: there is no other way
06:20 tanure: ok, so if nouveau isn't working ( gpu with bo firmware) should fallback to intel right ?
06:20 karolherbst: no
06:20 karolherbst: intel runs _always_
06:20 karolherbst: intel rules your main display and your desktop
06:20 karolherbst: always
06:20 karolherbst: no exception
06:21 karolherbst: as long as your main display is connected with your intel gpu ;)
06:21 karolherbst: so
06:21 karolherbst: first question: where is your main display connected to
06:21 tanure: nvidia
06:21 karolherbst: okay
06:22 karolherbst: now is the question, what do you want to have: intel ruling your world, or nouveau ruling your world
06:22 tanure: intel
06:22 RSpliet: karolherbst: nouveau isn't going to rule the world
06:22 RSpliet: it's a GM2xx, no firmware
06:22 karolherbst: ahhh
06:22 karolherbst: then intel
06:22 tanure: yeah
06:22 karolherbst: tanure: then you have to connect your main display to your motherboard
06:22 tanure: doesnt work
06:23 karolherbst: mhhh
06:23 karolherbst: okay
06:23 karolherbst: I have an idea
06:23 karolherbst: tanure: lspci output please
06:23 RSpliet: karolherbst: randr recognises both providers (intel and modeset)
06:23 RSpliet: so all it should take is define modeset as the sink, intel as the render target
06:23 karolherbst: :/
06:23 karolherbst: yeah well
06:23 karolherbst: but why do offloading if you can simply use the intel ports?
06:23 RSpliet: because he can't ;-)
06:24 karolherbst: well then we figure out why :D
06:24 RSpliet: tanure: is this a laptop?
06:24 karolherbst: RSpliet: I think it is a desktop
06:24 tanure: 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 Display controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI C
06:24 karolherbst: yep
06:24 karolherbst: 00:02.0 Display controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
06:24 karolherbst: k
06:24 RSpliet: hmm, Xeon laptops are rare :-P
06:24 karolherbst: :D
06:24 karolherbst: it is also Xeon for me
06:25 karolherbst: there are cheap and not so cheap mb chips
06:25 tanure: Desktop
06:25 karolherbst: and the not so cheap ones are usually identified as Xeons
06:25 karolherbst: tanure: can you connect via ssh to your desktop?
06:25 tanure: Linux ArchDesk 4.4.0-rc4-Linux-Next+ #9 SMP PREEMPT Thu Dec 10 17:08:16 BRST 2015 x86_64 GNU/Linux
06:26 karolherbst: ohhh wait
06:26 karolherbst: better idea
06:26 karolherbst: tanure: do you have a xorg.conf file?
06:26 tanure: no
06:26 karolherbst: k
06:26 karolherbst: then try this: shutdown your computer
06:26 karolherbst: connect the display to the motherboard
06:26 karolherbst: turn on your computer
06:26 tanure: I tried a few, but allways get black screen
06:26 tanure: doesn't work
06:26 karolherbst: mhhhh
06:26 tanure: black screen
06:27 karolherbst: then maybe the bios has some option?
06:27 RSpliet: tanure: could you check in your BIOS settings that "integrated" is your primary GPU?
06:27 karolherbst: could be that the bios is blocking it
06:27 tanure: I will check
06:27 tanure: but one question
06:27 tanure: My goal is
06:28 karolherbst: tanure: using a dispaly connected on your nvidia gpu is no problem when you run your desktop with the intel one
06:28 tanure: under windows, happy life, nvidia driver for games, under linux intel does everything and prints over nvidia hdmi port
06:28 RSpliet: tanure: hmm okay, in that case don't bother with checking your BIOS :-P
06:28 karolherbst: ohhhhh
06:28 RSpliet: as you don't want to keep switching ports on your computer when booting into Linux
06:28 RSpliet: so, back to reverse prime
06:29 karolherbst: now I understand what he is up to
06:29 karolherbst: :/
06:29 tanure: reverse prime seems to be for use 2 displays
06:29 karolherbst: yeah
06:29 tanure: =p
06:29 karolherbst: RSpliet: he wants one display
06:29 RSpliet: tanure: no
06:29 karolherbst: connected to nvidia
06:29 karolherbst: ran by the intel gpu
06:29 RSpliet: xrandr --setprovideroffloadsink Intel modeset
06:29 RSpliet: xrandr --setprovideroutputsource modeset Intel
06:29 RSpliet: or something like that
06:31 tanure: i will try
06:31 tanure: but this will close my current kde workstation
06:31 karolherbst: tanure: uninstall kscreen :D
06:32 tanure: why ?
06:32 tanure: kde needs right ?
06:32 karolherbst: not really
06:32 karolherbst: kscreen manages your display configuration
06:32 karolherbst: but it also reacts to stuff you do
06:32 karolherbst: so it may just mess up when you do the xrandr commands
06:32 karolherbst: later you can install it again
06:32 karolherbst: but for testing it is a bit "too smart"
06:32 tanure: donw
06:32 tanure: done
06:33 karolherbst: and maybe you should also kill it
06:34 karolherbst: then you can try out the commands from RSpliet
06:34 karolherbst: tanure: did you mean by killing kde it just stays black?
06:35 karolherbst: or it is restarted?
06:35 tanure: restart
06:35 RSpliet: yeah, although I'm not the best person to shout at if it doesn't work, I'm not the Optimus expert, just interpreting our wiki for you
06:35 karolherbst: tanure: yeah well, just do the both commands of RSpliet and it might still restart, but kscreen shouldn't mess up the settings
06:35 karolherbst: so it might work if you login
06:36 tanure: a few things stoped to work after killed kscreen
06:36 tanure: i need a few seconds to test
06:36 tanure: I will :
06:36 tanure: xrandr --setprovideroffloadsink Intel modeset
06:36 tanure: just that right ?
06:36 karolherbst: and the other one
06:36 tanure: xrandr --setprovideroutputsource modeset Intel
06:37 tanure: both ?
06:37 karolherbst: best thing is if you do "xrandr --setprovideroffloadsink Intel modeset && xrandr --setprovideroutputsource modeset Intel"
06:37 tanure: ok
06:37 RSpliet: oh, get the names right (sorry)
06:37 RSpliet: "xrandr --setprovideroffloadsink Intel modesetting && xrandr --setprovideroutputsource modesetting Intel"
06:38 karolherbst: RSpliet: reverse prime is still dri2 right? :/
06:38 tanure: i will reboot , a few thing got broken after kscreen removed
06:38 RSpliet: as I said, not the expert, just interpreting the wiki
06:41 karolherbst: Tanure2: I hope your resolution isn't messed up
06:41 Tanure2: xrandr --setprovideroffloadsink 0x4a 0x94 && xrandr --setprovideroutputsource 0x94 0x4a
06:42 Tanure2: http://pastebin.com/ED4sDA8e
06:43 karolherbst: does "xrandr --setprovideroffloadsink Intel modeset && xrandr --setprovideroutputsource modeset Intel" gives you a differfent output?
06:43 Tanure2: tanure@ArchDesk ~ $ xrandr --setprovideroffloadsink Intel modesetting && xrandr --setprovideroutputsource modesetting Intel X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 34 (RRSetProviderOffloadSink) Value in failed request: 0x4a Serial number of failed request: 16 Current serial number in output stream:
06:44 RSpliet: Tanure2: did you already pastebin a copy of your dmesg?
06:44 Tanure2: maybe my intel is broken?
06:44 Tanure2: http://pastebin.com/AveycV4u
06:44 Tanure2: dmegs
06:45 RSpliet: looks good
06:45 Tanure2: xorg log http://pastebin.com/HXBUJmKe
06:46 RSpliet: 'd you install the Intel libgl?
06:46 Tanure2: I think intel is ok
06:47 RSpliet: hmm, shouldn't be horribly relevant
06:47 RSpliet: for this error that is
06:47 Tanure2: https://wiki.archlinux.org/index.php/Intel_graphics , says :
06:47 Tanure2: To enable OpenGL support, also install mesa-libgl.
06:47 Tanure2: so, yes, I installed mesa-libgl
06:48 Tanure2: if I create a new /etc/X11/xorg.conf.d/20-intel.conf
06:48 Tanure2: bacl screen too
06:49 RSpliet: I don't think you need an xorg.conf
06:50 Tanure2: me too, for me this the basic stuff, if nouveau doesnt work fallback to intel, not gallium
06:50 RSpliet: anyway, I don't know how to debug the error message you get "integer parameter out of range for operation"
06:51 RSpliet: mlankhorst: ^ ?
06:51 Tanure2: karolherbst: you said that intel rules always , but we get a nvidia , how this works?
06:52 karolherbst: well it depends on how you want to do stuff
06:52 karolherbst: usually if you do prime offloading, you connect to your intel gpu
06:52 karolherbst: because that's the way with less resitant
06:53 karolherbst: Tanure2: it is important _where_ your display is connected too though
06:53 Tanure2: but my goal is too absurd ?
06:53 karolherbst: and first I thought you had a normal hybrid gpu setup
06:53 karolherbst: where the display is connected with the intel gpu
06:54 karolherbst: Tanure2: well, let me put it this way: your windows should be fine with a display connected to the intel card too
06:54 karolherbst: and games should be played on the nvidia gpu
06:55 Tanure2: where I should look to get this working ? fix my intel ? xorg ? what do you think ?
06:56 mlankhorst: RSpliet: -ERANGE
06:56 mlankhorst: RSpliet: there are only a few users for that, so I'd guess just check which one is used..
06:56 Tanure2: for you my display should be connected to my motherboard, and even under windows I will be ok to play games using my nvidia
06:57 RSpliet: mlankhorst: sorry, I was hoping you'd know off the top of your head what could be wrong. Some old/known bug or an issue with DRI2 O:-)
06:57 mlankhorst: no idea
06:57 RSpliet: darn! :-)
06:58 karolherbst: Tanure2: yeah, should work
06:58 karolherbst: that will give you less pain on the linux side
06:58 karolherbst: might reduce gaming performance though by a little
06:59 Tanure2: ok, I will take a look, or at least changing the hdmi is not that bad, I just want a better opengl render to work with wayland
06:59 RSpliet: karolherbst: can you actually configure that to work under Windows?
07:01 Tanure2: I'm looking this problem for another reason , maybe I can develop a kernel / nouveau code to handle my case
07:02 Tanure2: if gallium can print under nvidia, there is a way to intel does too
07:02 RSpliet: Tanure2: if the "Reverse prime" method does not work for whatever reason (including the error you got), this should be considered a bug
07:03 karolherbst: RSpliet: it should just work out of the box
07:03 Tanure2: ok, So I send a e-mail to nouveau and start a thread for that ?
07:03 pmoreau: Aren't you going to get gallium rather than Nouveau since Nouveau doesn't support acceleration on GM20x?
07:04 RSpliet: pmoreau: the goal is to get his IGP to render and use "modesetting" as it's output sink
07:04 pmoreau: Right, but I'm mostly reacting to "if nouveau doesnt work fallback to intel, not gallium"
07:05 Tanure2: pmoreau: but this is the best right ? use the hardware that you have, not a software solution
07:05 karolherbst: Tanure2: I said it before: it depends on where your dispaly is connected to
07:06 karolherbst: the intel gpu can't just magically render on a display connected to the nvidia gpu
07:08 Tanure2: but the algorithm it's straightforward : 1 - ok I have a nvidia card, load nouveau
07:08 Tanure2: 2 - nouveau doesnt support this card
07:08 Tanure2: 3 ask i915 to render over the connected display
07:09 pmoreau: Isn't this going to be a problem in setting up reverse PRIME? "(II) AIGLX: Screen 0 is not DRI2 capable"
07:09 karolherbst: Tanure2: well, you can define every algorithm you want, but this doesn't mean the hardware will actually do that
07:10 Tanure2: =p
07:10 karolherbst: Tanure2: the intel card, can't talk to the display connected to the nvidia card
07:10 karolherbst: there is no way
07:10 karolherbst: it simply can only copy some buffer containing display data to the nvidia card
07:10 karolherbst: well maybe even that it can't but the cpu for sure
07:11 RSpliet: karolherbst: that's exactly what (reverse) prime does...
07:11 karolherbst: I know
07:11 karolherbst: Tanure2: currently your desktop runs on the nvidia card
07:11 Tanure2: yes
07:12 RSpliet: let's focus on pmoreau's comment instead
07:12 karolherbst: Tanure2: and with the offloading stuff we try to move that to the intel card ;)
07:12 RSpliet: yes, that sounds like a serious issue... is that because it's using modesetting instead of nouveau?
07:12 karolherbst: could be
07:12 karolherbst: does modesetting can DRI2 at all?
07:13 pmoreau: I would have said so off hand, but… no idea
07:13 RSpliet:puts on his dunce hat - how many monkeys does it take to get why reverse prime doesn't work... apparently 4 :-P
07:13 Tanure2: =p
07:13 pmoreau: RSpliet: And how many does it take to fix it? :-P
07:14 RSpliet: none, just a gorilla
07:14 Tanure2: isn't fault of my nvidia card, too new ?
07:14 RSpliet: I'd dive into it deeper my PhD work wasn't Piled higher and Deeper
07:16 pmoreau: :-)
07:16 karolherbst: Tanure2: no, it is only nvidias fault
07:16 karolherbst: I don't even fell bad blaiming nvidia, because it is really just their fault
07:16 pmoreau: [ 3.450] (II) glamor: EGL version 1.4 (DRI2):
07:16 pmoreau: [ 3.451] EGL_MESA_drm_image required.
07:16 pmoreau: [ 3.451] (EE) modeset(0): glamor initialization failed
07:16 pmoreau: Guess that's why there is no DRI2
07:17 karolherbst: except when failing to crach a RSA key is a blaimfully failure, then it is nouveau fault :D
07:17 karolherbst: *blaimful
07:17 karolherbst: pmoreau: yeah, most likely :/
07:17 karolherbst: thing is, we don't even need glamor
07:18 karolherbst: or do we?
07:18 pmoreau: I'm not even sure what glamor is, so… :-D
07:18 karolherbst: pmoreau: 2d accell over opengl
07:18 pmoreau: Ok
07:19 karolherbst: the new shit working for every gpu, but it doesn't compete well enough with SNA so far on intel :D
07:19 mlankhorst: RSpliet: in most cases its fb parameters out of range
07:20 RSpliet: mlankhorst: sorry, could you clarify that statement please? are you talking about dims, bpp kind of parameters?
07:24 pmoreau: Weird, it looks like EGL_MESA_drm_image was added to Mesa in 2010…
07:24 pmoreau: Tanure2: I guess you have Mesa 10.7 or 11.0?
07:24 Tanure2: 11.0
07:25 Tanure2: mesa 11.0.7-1 mesa-libgl 11.0.7-1
07:25 Tanure2: think to switch to mesa-git and compile with --enable-dri3
07:25 RSpliet: pmoreau: it's arch iirc
07:25 Tanure2: thinking*
07:25 pmoreau: Oh right… My question should have been 11.0.7 or 11.1.0 :-D
07:26 pmoreau: RSpliet: Right, just wondering if he was on the extra package or testing one
07:37 Tanure2: ideas ? check dri2 ?
07:44 pmoreau: Sorry, no idea. The Mesa Arch package is compiled with EGL support, so it should have that EGL extension.
07:48 Tanure2: and dri too ?
07:49 pmoreau: Yes
07:49 pmoreau: But not dri3
07:49 Tanure2: it matters?
07:50 pmoreau: Well, you should still be able to use DRI2, which *should* work.
07:52 Tanure2: so the problem is nouveau?
07:54 pmoreau: Maybe, maybe not, I don't know. glamor initialisation initiated by modeset fails, but I have no idea where the blame should be placed.
07:55 Tanure2: there is anything that I can do ?
07:56 pmoreau: Find someone who understands the interaction between glamor, modeset & co. (I don't, so I can't tell you what you should try)
08:04 Tanure2: karolherbst: I'm a newbie in this area of gpu, so far I understand that I have a bug here, but didn't understand very well, could you help to understand what is happening ?
08:05 karolherbst: Tanure2: you could try out this: connect the display to your motherboard and boot windows and see if this works
08:06 karolherbst: but regarding the offload thing I have no idea either
08:06 Tanure2: =p
08:06 Tanure2: ok, thanks!
08:07 Tanure2: my main problem is : 4.164] (II) AIGLX: Screen 0 is not DRI2 capable
08:07 Tanure2: ?
08:07 Tanure2: I want a start point so I can trace the problem
08:09 karolherbst: Tanure2: what version of the xorg-server are you using?
08:10 Tanure2: xorg-server 1.18.0-3
08:11 karolherbst: Tanure2: add root to the video group and restart X
08:12 Tanure2: already is
08:12 Tanure2: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log),91(video)
08:13 Tanure2: I will test windows with hdmi from motherboard
08:13 Tanure2: and start linux in this config to get dmes
08:13 Tanure2: dmesg
08:14 Tanure2: thanks, I will come back in minutes
08:18 karolherbst: neither llvmpipe nor i965 have the EGL_MESA_drm_image here :/
08:19 karolherbst: ohh wait, i965 has it
08:19 karolherbst: nouveau too
08:20 karolherbst: pmoreau, RSpliet found it :)
08:20 karolherbst: llvmpipe simply doesn't support EGL_MESA_drm_image
08:20 pmoreau: :-/
08:20 karolherbst: maybe softpipe or swrast do
08:20 karolherbst: but I don't have them installed
08:27 karolherbst: pmoreau: but that just means that he has no 2D accell at all
08:32 imirkin: you guys are solving the wrong problem
08:33 imirkin: he has the same situation as one of those ARM gpu setups -- display controller without accel, 3d controller without display
08:34 imirkin: i was under the impression that there was logic in modesetting to fall back to another render node
08:34 imirkin: either way, nouveau is in no way related to the issue at hand
08:35 imirkin: pmoreau: maybe. why isn't lval->defs.size() == 0 then?
08:36 tanure: Hi
08:37 tanure: So, windows + gtx 970 + display connect to motherboard WORKS
08:37 tanure: games at this configuration are terrible
08:37 pmoreau: imirkin: Oh right, there is that additionnal check. I'll have a closer look at it… when I get some time.
08:37 tanure: it uses intel only
08:37 imirkin: tanure: check logs
08:37 imirkin: (irc logs)
08:38 tanure: checked
08:39 tanure: what I can do ?
08:39 imirkin: i guess what i'm saying is that your questions are misdirected
08:39 tanure: ps: LINUX + gtx 970 + display connect to motherboard , DONT work
08:40 imirkin: you could try #xorg-users or #xorg-devel. afaik this use-case is rare and it's not a well-trodden path
08:40 imirkin: i.e. display controller on one gpu, and glamor 3d accel on other gpu
08:41 imirkin: perhaps gnurou or tagr_ or mlankhorst know how to get it going
08:41 imirkin: or anholt (but he's not in this channel)
08:42 tanure: but whats is happing here ? xorg issue?
08:42 imirkin: yep
08:42 imirkin: and/or lack-of-feature
08:42 tanure: how I can explain my issue to another person ?
08:43 imirkin: you would like to use modesetting to run display off of a 2d-only gpu, and have glamor operate off of your other 3d-capable gpu
08:43 imirkin: (that's basically the situation right?)
08:44 mupuf: karolherbst: sounds very probable!
08:45 tanure: modesetting to run display off of a 2d-only gpu (nouveau withou firmware ), and have glamor operate off of your other 3d-capable gpu (intel)
08:45 tanure: right?
08:45 imirkin: yeah, but i'd leave the brand names out
08:45 tanure: ok, I just want to understand
08:46 imirkin: it'll just confuse people, they'll think you have optimus, or a laptop, or whatever
08:46 tanure: So, it's possible to use intel with the HDMI from gtx-970?
08:46 imirkin: in theory, sure
08:47 tanure: and xorg guys could help?
08:47 imirkin: in practice, it's not a well-trodden path
08:47 imirkin: they could authoritatively tell you if that use-case is presently supported or not
08:47 tanure: ok, many Thanks!
08:56 mupuf: tanure: tried that last week actually
08:56 mupuf: plugged a lot of gpus and tested importing connectors from different gpus
08:56 tanure: LINUX + gtx 970 + display connect to motherboard ???
08:56 tanure: what you got ?
08:57 mupuf: it worked quite well on TWM, but it crashed the xserver with kwin
08:57 mupuf: well, I was not using a 970, but it should be the same
08:57 mupuf: it was an intel gpu and 2 nvidia gpus
08:58 mupuf: there is just one command needed and that should be working
08:58 tanure: well, this firmware problem it's the worst
08:58 imirkin: mupuf: it's not about importing connectors
08:58 tanure: So, why is not working here?
08:58 mupuf: maybe it does not work with the modesetting driver though
08:58 imirkin: mupuf: what you tested was a wholly different thing
08:59 tanure: its modesetting because I don't have the firmware for the gpu right ?
08:59 karolherbst: mupuf: anyway, on my fermi with the blob I found out that there are three different thresholds leading to three different dividers :/
09:00 karolherbst: and it wasn't THRESHOLD_4
09:00 karolherbst: but 8
09:01 karolherbst: thr8 => div 2, thr6 => div6, thr2 => div e
09:01 karolherbst: but I didn't see where to configure the thr8 one
09:01 mupuf: imirkin: well, use the intel gpu for rendering and the nvidia one for display
09:01 imirkin: mupuf: and is that what you had?
09:02 mupuf: I fail to see what is wrong with it, this is a pure optimus case :s
09:02 imirkin: mupuf: coz i think you had something totally different
09:02 mupuf: I was rendering on the intel gpu and displaying on two other nvidia gpus
09:02 karolherbst: mupuf: is glamor working required?
09:02 imirkin: mupuf: perhaps that's how it worked out, but that's not what was going on
09:03 imirkin: mupuf: what was the primary gpu?
09:03 mupuf: Sorry, I have a ping of 8s so I answer slowly
09:03 mupuf: no, why would glamor be related to this?
09:03 karolherbst: DRI2?
09:03 karolherbst: I don't know when you got DRI2, just asking
09:03 mupuf: the primary gpu was the intel one
09:03 mupuf: but if you want to use another one, use DRI_PRIME
09:03 imirkin: mupuf: exactly. so... not the scenario being discussed.
09:04 mupuf: ok, then I misunderstood, will check again
09:04 karolherbst: tanure: did you test display connected to intel on windows?
09:04 tanure: yes
09:04 karolherbst: and?
09:04 imirkin: mupuf: he wants the ARM case -- display on, say, tegra, accel on, say, nouveau
09:04 tanure: windows + gtx 970 + display connect to motherboard WORKS
09:04 karolherbst: k
09:04 tanure: games at this configuration are terrible
09:04 karolherbst: tanure: yeah well, maybe you need to configure nvidia a bit to get that working this way
09:05 karolherbst: okay, but now we know that the mb port is connected to the intel gpu
09:05 mupuf: imirkin: the ARM case is the same as the optimus case, just simpler
09:05 imirkin: tanure: i said this before, but i'll repeat it in case you didn't quite get it -- your situation has absolutely nothing to do with nouveau
09:05 karolherbst: and it should work even with linux
09:05 karolherbst: tanure: okay, idea
09:05 imirkin: mupuf: not at all. optimus case is gpu 1 has display + accel. gpu 2 has accel (and maybe display)
09:05 imirkin: mupuf: when gpu1 doesn't have accel, things get trickier.
09:06 mupuf: so what? prime separates rendering from display
09:06 imirkin: prime is ... totally unrelated
09:06 karolherbst: I think the issue is, that we don't get DRI2 working here
09:06 imirkin: not sure what prime has to do with this
09:06 imirkin: when i call XDrawRectangle() what does prime have to do with this?
09:06 imirkin: (don't know if such a command exists, but you get the point)
09:07 mupuf: how so? DRI_PRIME tells which gpu to use for rendering, then xrandr allows you to import connectors to another driver
09:07 mupuf: and let X handle the copy
09:07 karolherbst: tanure: output opf "LIBGL_DEBUG=verbose glxinfo >/dev/null" please
09:07 imirkin: ok. so... spend some time thinking about why i'm right :)
09:07 tanure: libGL: screen 0 does not appear to be DRI2 capable
09:07 karolherbst: tada
09:07 tanure: libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/swrast_dri.so
09:07 tanure: =p
09:07 karolherbst: so we don't have DRI2
09:07 karolherbst: we don't have DRI3 either
09:08 imirkin: you guys are focusing on the wrong stuff
09:08 karolherbst: so how can prime offloading work this way?
09:08 imirkin: 3d accel has nothing to do with the issue here
09:08 karolherbst: and I thoguht you _need_ dri2 for reverse prime
09:08 mupuf: Are you really trying to do 2d accel on another gpu? How useless is that :D
09:09 karolherbst: mupuf: well when you don't ahve 2d accel on your main gpu ;)
09:09 imirkin: karolherbst: that's not the case, and also not related to the issue.
09:09 imirkin: mupuf: think about how modesetting works.
09:10 mupuf: well, it uses gl to provide the 2d accel
09:10 imirkin: right
09:10 mupuf: and it uses mesa
09:10 imirkin: huh?
09:10 imirkin: it uses libGL
09:10 mupuf: sure sure
09:10 imirkin: and if the main gpu doesn't support accel
09:10 imirkin: then...
09:10 mupuf: but mesa supports DRI_PRIME
09:10 karolherbst: mhh couldn't we just start X with DRI_PRIME=1 then and let glamor use the opengl stuff from the intel gpu? :D
09:10 imirkin: gah!
09:10 imirkin: what does DRI_PRIME have to do with this?
09:11 imirkin: this isn't like some separate application that interacts with X
09:11 imirkin: this *is* X
09:11 imirkin: alright. i'm done. i don't think i can handle this anymore. good luck.
09:12 urjaman: it's okay
09:12 mupuf: I get your point, but this still does not mean it is not possible. It will requires some changes though, probably
09:12 karolherbst: starting with X with DRI_PRIME sounds so crazy, I try that out :D
09:13 mupuf: karolherbst: if it uses dmabuf for importing buffers, then I don't see why it would not work
09:13 karolherbst: yeah I don't either
09:13 mupuf: but yeah, it is crazy :D
09:13 karolherbst: well but this is the issue here right?
09:13 mupuf: but it is likely not tested
09:13 karolherbst: he don't get 2d accell cause of modesetting not working
09:13 karolherbst: well
09:13 karolherbst: glamor not working
09:13 karolherbst: so why don't just render glamor on the intel gpu
09:13 karolherbst: and display on modesetting
09:14 mupuf: but seriously, why do you even do this? Just disable the 2d accel and be done with it. Noone uses the 2d accel anyway
09:14 karolherbst: and if he needs gl he can just start stuff with DRI_PRIME and render on intel
09:14 mupuf: set qt to use the raster engine and do the same for gtk
09:14 mupuf: and you are done
09:14 karolherbst: yeah right...
09:14 karolherbst: yeah we approached it from the wrong direction entirely
09:14 mupuf: well, X is retarded anyway
09:15 karolherbst: mupuf: how can someone choose a gpu through DRI_PRIME explicitly?
09:15 karolherbst: was it the pci id?
09:15 karolherbst: bus id?
09:15 karolherbst: not sure anymore
09:15 imirkin: mupuf: i didn't say it wasn't possible
09:15 karolherbst: ohhh I know, we start kwin with DRI_PRIME :)
09:15 imirkin: mupuf: i said "this is not what you tested"
09:15 imirkin: and "this has nothign to do with prime"
09:15 mupuf: agreed
09:15 imirkin: and "this is exactly like the arm case"
09:16 mupuf: yep, true, but it has to do with prime, as in the kernel side, to share buffers
09:16 karolherbst: tanure: "DRI_PRIME=1 glxinfo | grep vendor" what does this give you?
09:16 imirkin: mupuf: aka dma-buf
09:16 tanure: server glx vendor string: SGI client glx vendor string: Mesa Project and SGI OpenGL vendor string: VMware, Inc.
09:16 imirkin: and yes, it does have to do with that
09:17 karolherbst: tanure: and "DRI_PRIME=0 glxinfo | grep vendor"
09:17 imirkin: karolherbst: won't work. X server won't have the proper setup for glx/etc.
09:17 mupuf: karolherbst: there are ways, you still need to run the xrandr command to import the render part of the gpu
09:17 mupuf: and then glamor could start working
09:17 tanure: server glx vendor string: SGI client glx vendor string: Mesa Project and SGI OpenGL vendor string: VMware, Inc.
09:17 karolherbst: ohhhh right
09:17 karolherbst: tanure: xrandr --setprovideroffloadsink Intel modesetting
09:17 karolherbst: does that work?
09:17 karolherbst: mhh
09:17 tanure: X Error of failed request: BadValue (integer parameter out of range for operation)
09:17 mupuf: not sure if modesetting supports doing this
09:17 karolherbst: right glx won't work
09:18 karolherbst: right, I try out a setting where intel is using modesetting, nouveau is using nouveau, and I do glamor over DRI_PRIME
09:18 mupuf: but again, it is a futile exercise
09:18 mupuf: it is useless
09:19 imirkin: karolherbst: won't work. intel has accel.
09:19 mupuf: but yeah, talking about the fw, too bad we will have to wait for a couple more weeks :s
09:20 mupuf: now, I need to have a nap, I slept 3h tonight and have been travelling since 5am :s
09:20 mupuf: will see pmoreau and hakzsam tonight :)
09:20 tanure: guys, sorry for the inconvenient, but could you explain what your are think in a newbie language ? Just for me understand a little more the conversation =p
09:23 pmoreau: mupuf: Did I missed something? You're both in Sweden today? O.O
09:23 imirkin: pmoreau: no, you're being kidnapped
09:23 pmoreau: Ahhhhhhhhhhhh! :-(
09:24 pmoreau:has disappeared in some alien spaceships…
09:24 pmoreau: s/spaceships/spaceship
09:26 mupuf: pmoreau: sorry, hakzsam meant another pierre :D
09:27 pmoreau: :-D
09:27 mupuf: He meant Pierre Papier-Ciseaux
09:27 pmoreau: :-p
09:28 karolherbst: okay, I can't tell glamor to use my nouveau card :(
09:28 pmoreau: mupuf: Go back to your Finnish lessons! :-D
09:28 imirkin: Finnish your Finnish!
09:28 mupuf: pmoreau: i'll dream about them then, during my nap
09:28 pmoreau: imirkin: Nice one!
09:28 mupuf: Got my exam yesterday, it was baaaadddd
09:29 imirkin: language is hard
09:29 mupuf: everyone just said fuck it and they had enough Finnish until the next september
09:29 mupuf: I will be alone in class :s
09:29 mupuf: insane is a better word
09:30 mupuf: kind of nice, in a way, -ish, but insanely different
09:31 mupuf: sooda would disagree, and would probably laugh at our conversation in Finnish too :D
09:31 mupuf: anyway, need a nap, ttyl guys!
09:32 tanure: karolherbst: what I need to understand to understand the issue ? My pc has no DRI2 and DRI3 , so glamor doesn't work, right?
09:33 tanure: my nvidia is in modesetting mode, because nouveau doesn't have the firmware to work better
09:36 karolherbst: what does "modeset(G0): [DRI2] DRI driver: nouveau" mean?
09:38 karolherbst: ohh no, the modesetting driver just claimed both of my cards :/
09:39 tanure: karolherbst: could you help me to understand what you guys talked , and the conclusion ?
09:42 karolherbst: tanure: not quite sure, but I think if you want to get proper 2d/3d accel on linux you should try to get the motherboard port working on linux
09:42 karolherbst: that's at least the way with the less amount of pain
09:43 tanure: and the idea that I said, get intel work under nvidia HDMI port is possible ?
09:43 karolherbst: tanure: do you have a second computer and could ssh to your desktop while the display is connect to the motherboard? I expect randr to mess up a bit or X
09:43 karolherbst: yeah, you can offload the port to your intel gpu this way
09:44 karolherbst: well
09:44 karolherbst: offload the intel rendering to the port
09:44 tanure: yes, I have a laptop
09:44 tanure: So, I check the status of X under that config
09:45 karolherbst: yes
09:45 tanure: anything else?
09:45 karolherbst: no
09:45 karolherbst: well you can open irc on the laptop and post the logs :D
09:45 tanure: :D of course
09:46 tanure: xrandr --setprovideroffloadsink will not work any way
09:46 tanure: because I have bad software , right ?
09:46 karolherbst: well we will play with that after you get output on the display
09:47 tanure: bye
09:49 Tanure: hi
09:49 Tanure: =p
09:54 Tanure: black screen
09:54 Tanure: xorg log http://pastebin.com/yKLnrL2P
09:59 imirkin: no screens are connected (according to it)
09:59 imirkin: grep . /sys/class/drm/card*-*/status
10:00 Tanure: http://pastebin.com/V8rSjvFF
10:03 imirkin: either way, looks like the screen is plugged into the intel gpu
10:03 imirkin: but you're using nvidia as the primary
10:03 imirkin: none of this has to do with nouveau btw
10:03 imirkin: please address your questions to the proper channels
10:04 Tanure: ok, thanks!
10:09 hakzsam: mupuf, ping
10:10 hakzsam: mupuf, you don't need to sleep because wa have to drink beers :-)
10:11 hakzsam: mupuf, and yeah, it's not pmoreau ;)
10:12 hakzsam: imirkin, btw, thanks for pushing my patch today. I'll have a look at the bind_compute_state and the little asm improvement thingstomorrow
10:15 mupuf: pong, on my way
10:34 RSpliet: mupuf: was that a beer pong?
10:39 hakzsam: :)
10:43 pmoreau: imirkin: Hum, I was going to say: "What if the def wasn't decremented after the artificial move tied to r0 is removed by the DeadCodeElim pass?" but that would have had a more visible impact I guess.
10:43 pmoreau: Except maybe if there is also one def due to being a function input
10:46 imirkin_: pmoreau: if the instruction is deleted, it should remove itself from the defs
10:46 imirkin_: HOWEVER
10:46 imirkin_: there's a fun little effect
10:46 imirkin_: where sometimes ops are *removed* but not deleted
10:46 imirkin_: but in that case... lvalue should still have the insn pointer
10:46 imirkin_: yeah dunno
10:48 pmoreau: I'll try to trace it, I shouldn't have that many LValue alive.
10:48 imirkin_: when i was debugging it there were quite a few
10:48 pmoreau: Any places in particular in the code I should check?
10:48 pmoreau: :-/
10:58 imirkin_: mupuf: karolherbst: btw i was off in my recollections -- there's plain no way to do this with modesetting.
11:02 imirkin_: gnurou: you have got to be kidding me... that gk20a astc situation is *ridiculous*
11:02 imirkin_: gnurou: almost makes me want to power mine up and see the insanity...
13:12 imirkin_: ugghhhh... mmt is broken again :(
13:12 imirkin_: unknown type: 0x4e
13:13 imirkin_: or rather... demmt
13:13 imirkin_: joi: know what that type is offhand? is it the mmt being corrupted?
13:13 imirkin_: joi: http://hastebin.com/imucohudif.sm
13:14 imirkin_: fourcc of 'NEG ' it seems
13:15 imirkin_: looks like it's from dump_state?
13:18 joi: imirkin_: yup, mmt crashed
13:19 imirkin_: hmmmm
13:19 imirkin_: indeed.
13:19 imirkin_: thoughts?
13:20 joi: look at the dumped state
13:20 imirkin_: this is with 358.16
13:20 imirkin_: joi: http://hastebin.com/rolupasame.coffee
13:22 joi: imirkin_: two negative regions overlap (2nd and 3rd), it should not happen
13:22 imirkin_: and yet... here we are :)
13:22 imirkin_: i haven't the faintest clue what a negative region is btw
13:22 joi: I'd uncomment MMT_DEBUG and obtain a trace again
13:23 imirkin_: and rebuild valgrind presumably? :)
13:23 joi: yeah
13:23 Lekensteyn: karolherbst: GTX 965M (GM204, but not on wiki/CodeNames?) seems to need signed firmware (promised a year ago), is there any progress on getting these from nvidia?
13:23 Lekensteyn: I don't see communication other than http://lists.freedesktop.org/archives/nouveau/2015-June/021255.html
13:23 imirkin_: joi: MMT_DEBUG appears to be defined out of the box
13:24 joi: MMT_DEBUG_VERBOSE? or something like that
13:24 imirkin_: Lekensteyn: moderate progress, but nothing too much. we're told that code exists to load this firmware on dgpu's with nouveau, but no word on actually getting it (the code or firmware) released in a distributable manner
13:24 joi: mmt tries hard not to look at complete map of memory when deciding whether to save read or write
13:25 imirkin_: rebuilding...
13:26 Lekensteyn: imirkin_: from that mailing list post (and the earlier one from 2013) Andy (?) mentioned that distribution shouldn't be a problem (license-wise?), isn't that the case?
13:26 pmoreau: Lekensteyn: There has been progress: the loading firmware code for dGPU should be submitted quite soon I guess, and
13:26 pmoreau: < gnurou> urgh, and it seems like that contrary to my plans, the GM20X firmwares won't be released before the end of year... so sorry about that :(
13:26 imirkin_: joi: http://hastebin.com/apenafehur.md
13:27 pmoreau: But most likely early 2016
13:27 imirkin_: joi: not sure how to grep all those prints out from mmt
13:27 imirkin_: Lekensteyn: i can only report on things that have happened.
13:27 imirkin_: Lekensteyn: and there has been no such firmware release
13:29 imirkin_: joi: sounds like an issue merging those 2 entries when the start address is 0?
13:30 joi: imirkin_: "negative regions" is a list of recent "misses"
13:30 joi: imirkin_: probably
13:30 Lekensteyn: ok, I'll get the new laptop in the next weeks, would be happy to try some patches for improved gm204 support. All I need it for is multi-monitor, no gaming
13:30 imirkin_: joi: these are a few things that happened beforehand: http://hastebin.com/sapucixeho.xml
13:31 imirkin_: Lekensteyn: gm204 modesetting should work fine
13:31 MichaelLong: Lekensteyn, sure you want to buy a laptop with nvidia in it?
13:32 imirkin_: i'd definitely recommend against buying nvidia hw for use with linux
13:34 MichaelLong: I've an oldish Thinkpad T530 with optimus, but I use it with disabled intel gpu. it make things more complex, especially with multi-monitor use.
13:34 Lekensteyn: MichaelLong: nope, but it was the best compromise I could find. http://www.clevo.com.tw/clevo_prodetail.asp?id=856&lang=en
13:35 joi: imirkin_: the bug is in mmt_trace.c:318
13:35 MichaelLong: wow this is a pretty ugly one, plus it has a numlock oO
13:35 Lekensteyn: MichaelLong: currently I've Clevo B7130, but it's 8GB RAM, broken Ethernet port, half-loose power/mobo thingey are a bit limiting
13:35 imirkin_: joi: not familiar enough with the code to see it
13:36 Lekensteyn: I like numlock, and initially I'll shove 32GB into it (can upgrade to 64 in the future if I really get crazy)
13:36 joi: imirkin_: it assumes there are no negative entries before first mmap
13:36 MichaelLong: Lekensteyn, ok more than 16 GB is neat
13:36 Lekensteyn: It has a Skylake CPU which supports MPX (a variant of AdressSanitizer), that is the main reason why I don't go for an i7-4xxx
13:37 imirkin_: joi: so there are positive and negative regions... are they ever overlapping?
13:37 joi: imirkin_: as a quick workaround you could comment out both "before first" and "after last" blocks
13:37 imirkin_: ok
13:37 joi: imirkin_: no, never
13:37 imirkin_: joi: and they are presumably sorted?
13:38 joi: "positive regions" is a list of all mmaped regions
13:39 Lekensteyn: MichaelLong: oh, and the battery life is apparently decent (6h, likely intel mode). If you know something like that, but with just an Intel GPU I am all ears :)
13:39 imirkin_: joi: mmaptrace: mmt_trace.c:144 (__verify_state): Assertion 'neg1->start <= neg1->end' failed.
13:39 imirkin_: http://hastebin.com/nutowobeju.pl
13:40 MichaelLong: Lekensteyn, only 6h?
13:41 Lekensteyn: MichaelLong: it's quite an upgrade from my current 3-4h, if I need more battery I will probably consider a less powerful, smaller form-factor device in the future
13:42 pmoreau: Even my 6 year old laptop with its 6 year old battery can reach (hardly, but still) 6h of battery life
13:43 imirkin_: Lekensteyn: looks like the lenovo ideapad line has skylake cpu's
13:43 joi: imirkin_: heh
13:43 imirkin_: don't seem to be any thinkpads... sad
13:44 Lekensteyn: lenovo is on my blacklist due to their superfish crap on the consumer line
13:44 MichaelLong: Lekensteyn, this is extremly low for 2015. my private ultrabook (all intel) does about 9-10h with light usage (some programming, web surfing) the aformentioned old T530 tops out at about 9h (in windows never even close in linux)
13:44 imirkin_: joi: did i mess up?
13:44 Lekensteyn: and also their idiocratic blacklist for things like wifi cards
13:44 joi: imirkin_: comment out all add_neg calls if you want to have it workarounded really quick
13:44 imirkin_: just add_neg, i.e. do i still want return null?
13:45 joi: imirkin_: mmt will probably be much slower
13:45 imirkin_: joi: i.e. can i just make add_neg return internally?
13:45 Lekensteyn: MichaelLong: but that has a i7-xxxxU processor, this one has a i7-6700HQ which is about as fast as a desktop i7-3770 apparently
13:45 Lekensteyn: imirkin_: can you add GTX 965M to the CodeNames wiki page?
13:45 imirkin_: joi: aha much better!
13:45 joi: imirkin_: yeah, that would work
13:45 MichaelLong: I still keep that old laptop at work because its NVS 5300 is extremly well supported (except reclocking)
13:45 imirkin_: joi: of course demmt can't deal with those printfs :(
13:46 imirkin_: sweet, it worked
13:46 joi: imirkin_: if you want to fix it for real, "before first" and "after last" blocks need to be fixed
13:47 imirkin_: joi: can you elaborate how one might fix them?
13:47 joi: ... by taking into account other "negative regions"
13:48 joi: you need to add negative region that don't overlap with any other
13:49 imirkin_: joi: isn't it add_neg that needs fixing then?
13:49 joi: hmm, yeah...
13:55 imirkin_: gnurou: ok, well, tracing the blob (358.16) driver on my GK208 doesn't make it seem like it uses those ETC2 TIC formats
14:17 imirkin_: can someone with a GK10x see if this patch http://hastebin.com/kadinotusa.md allows e.g. bin/ext_texture_array-compressed_gles3 teximage to work?
14:17 imirkin_: karolherbst: if you're up for it --^
14:24 karolherbst: imirkin_: yeah can do that in a sec
14:24 imirkin_: karolherbst: actually replace FLOAT with UNORM in there -- i was just messing around
14:24 imirkin_: karolherbst: for the first 2 formats
14:27 karolherbst: k
14:27 karolherbst: should I run a full piglit test?
14:29 karolherbst: well this tests fails on intel and nouveau for me without your patch anyway
14:30 karolherbst: ohh wait
14:30 karolherbst: I have to add a parameter
14:30 imirkin_: yes... teximage... ;)
14:30 karolherbst: imirkin_: the test already passes without your patch
14:30 imirkin_: i know
14:30 imirkin_: but it's using sw decoding
14:30 karolherbst: ohhh
14:30 karolherbst: so less perf
14:31 imirkin_: mmmm... questionable
14:31 karolherbst: oaky, so why then let the hardware doing this?
14:33 imirkin_: i just mean that i have no clue if it's faster
14:34 imirkin_: i'm sure there's a tradeoff somewhere
14:45 karolherbst: mhh I need to renew my thermal paste :/
14:45 karolherbst: cpu boost to -150MHz
14:46 imirkin_: karolherbst: so did you test it?
14:46 karolherbst: still compiling :(
14:47 imirkin_: oh, i figured you had a tree all ready
14:47 karolherbst: yeah well
14:47 karolherbst: gcc upgrade
14:47 karolherbst: it would rebuilt everything anyway
14:47 karolherbst: so I just update my system mesa
14:48 imirkin_: hehe ok
14:48 karolherbst: seems to be finished any seconds now anyway
14:48 karolherbst: ohh right, already install phase
14:49 karolherbst: it passes
14:49 imirkin_: wtf???
14:49 imirkin_: are you sure?
14:49 karolherbst: ohhh wait
14:49 imirkin_: the gles3 one?
14:49 karolherbst: forgot DRI_PRIME
14:50 karolherbst: k, it does not pass
14:50 imirkin_: ok cool
14:50 karolherbst: yay
14:50 karolherbst: pmu messed up
14:50 imirkin_: gnurou: please double-check your docs on the etc2 thing... is it GK20A only perhaps?
14:50 karolherbst: https://gist.github.com/karolherbst/afac057f69f95d724567
14:50 karolherbst: imirkin_: well
14:50 imirkin_: that's not pmu
14:50 karolherbst: it isn't that wrong
14:51 karolherbst: last line
14:51 imirkin_: again, not pmu
14:51 karolherbst: ohh okay
14:51 imirkin_: that's the c800 thing
14:51 karolherbst: mhhh
14:51 karolherbst: k
14:51 karolherbst: well
14:51 karolherbst: it doesn't look that wrong actually
14:51 karolherbst: but not right either
14:52 imirkin_: probably a stale image
14:52 karolherbst: well
14:52 karolherbst: the gpu hangs everytime I start the test
14:52 imirkin_: it's not a hang
14:52 imirkin_: just errors in dmesg
14:53 karolherbst: well the process won't exit for a few seconds
14:53 imirkin_: -fbo -auto?
14:53 karolherbst: I meant even after kill
14:53 imirkin_: weird
14:53 karolherbst: ext_texture_arr[1625]: failed to idle channel 2 [ext_texture_arr[1625]]
14:53 imirkin_: oh yeah, you get a pte fault too
14:54 karolherbst: right, it was a stalled image
18:40 gnurou: imirkin_: you're right, it's GK20A only - found an internal doc confirming this. How do you know all that? :)
18:46 gnurou: imirkin_: Github PR updated
19:36 gnurou: skeggsb: just to confirm - would you mind if secure boot appeared as a nvkm subdev instead of being part of the code? I want to anticipate the fact that future chips may do things differently, and will require some abstraction
20:22 skeggsb: gnurou: sure
23:33 mlankhorst: RSpliet: dims in general, but easy to just add WARN_ON near every -ERANGE