00:17RSpliet: imirkin: sorry, missed your request earlier
00:18RSpliet: Do you have a concrete test case with that?
00:26RSpliet: Also, Firefox appears to be very happy to put Fermi's to its knees just by opening the suggestions on the address bar.
00:37RSpliet: Ok fuck this shit, never mind. Thermal shutdown killed my vibe
00:55imirkin: RSpliet: yeah, it's mentioned in the commit description
00:55imirkin: (it's in VK-GL-CTS)
00:57imirkin: RSpliet: you probably want to turn off the acceleration stuff in firefox
00:57imirkin: afaik it's a bit of a disaster
01:04RSpliet: imirkin: sorry, I'll test some other time
01:04RSpliet: Don't think I have the CTS
01:05RSpliet: As for FF, I was planning to dive into that at some point. Youtube videos don't play smoothly since whenever, there's defo going something wrong
01:06imirkin: no worries
01:23Manoa: hi guys
01:24Manoa: I have nouveau 17.1-rc3 on 780 Ti, would you recommend to update mesa to 18 when it come out soon for this card ? or are the changes in 18 only related to maxwell/pascal ?
01:25Manoa: the manual reclocking on this card is fully functional at the moment
01:38BootI386: For me, crashes in Firefox had the same cause iirc
02:34BootI386: imirkin: I was wrong. From backtrace at the moment it crashed it looks like it gets stuck here: http://termbin.com/mvb0
02:35BootI386: The crash happens inside this ioctl() that never returns
02:36twomix: anyone have any ideas what's going wrong here? https://pastebin.com/0cpczW62 been trying to get KMS to work but I dont even know if that's the problem
02:58imirkin: Manoa: master should have bindless textures, which you need to play certain games
02:58imirkin: Manoa: 17.1 is pretty old though ... i bet a ton of stuff has happened since. but perhaps not relevant to you.
02:59imirkin: lots of bug fixes happen, etc
02:59imirkin: twomix: without a useable vbios, nouveau won't work. it gets a ton of info from the vbios.
03:00imirkin: twomix: is there something funny about your configuration? i.e. different than the way the average user of such a GPU might have it set up?
03:01twomix: its a 2008 macbook pro with a fresh install of alpine linux.. I installed their xf86-video-nouveau package
03:01imirkin: is it one of the ones with both a MCP79 and a discrete gpu?
03:02imirkin: or does it only have a G84?
03:03imirkin: twomix: oh, you know, i have an odd recollection... some mac somewhere, when booting one way doesn't pass the bios through acpi properly.
03:03imirkin: so you have to supply the vbios explicitly
03:03twomix: gee not sure off hand.. would lspci tell me?
03:03imirkin: let me see if i can find the bug
03:03twomix: awesome thanks ive been stuck on this all evening
03:04imirkin: is it a MacBookPro3,1 ?
03:04imirkin: that's for 3,1
03:05imirkin: the reported thing was trouble booting with EFI but it worked with BIOS-style boot
03:05imirkin: is that an option for you?
03:05imirkin: basically you need to grab the vbios once, and then you can feed it in to nouveau via a file
03:09twomix: thank you this looks promising.. same exact card
03:10twomix: over my head, got some reading to do
09:50karolherbst: imirkin: ahh, right
09:51karolherbst: hakzsam: I only added that def thing, because it seems to be the right thing (tm)
09:52karolherbst: any I found the issue within an integer MAD produced after lowering some 64 bit int ops
09:52karolherbst: I think a mul or mad
16:42imirkin: karolherbst: any more maxwell-specific stuff i should look into before i unplug it?
16:51karolherbst: imirkin: how much do you know about that 3d images stuff?
16:52imirkin: for images, that doesn't affect maxwell though
16:52imirkin: since its surface ops handle tiled 3d images just fine
16:52karolherbst: I see
16:52karolherbst: so something else is screwed up?
16:52imirkin: that stuff all works
16:53karolherbst: not quite sure it fails because of some 3d image stuff, but maybe it does
16:53imirkin: ok, i'll fix it
16:53imirkin: i suspect it should be quite easy to do.
16:53karolherbst: and KHR-GL45.shader_image_load_store.incomplete_textures as well, but I think this was something stupid
16:53karolherbst: nice, thanks
16:54imirkin: (i think i know what the issue is, and it's something rather dumb)
16:54karolherbst: anyway, I don't know if you seen it, but I've udpated the CTS status for Pascal, which should be identical to Maxwell I think
16:54karolherbst: like a few days ago
16:55karolherbst: imirkin: ohh by the way, I was thinking for the builtins, maybe we should just be able to write shaders in nvir and generate binaries out of them which can be uploaded
16:55karolherbst: might make thinks a lot less painful
16:56karolherbst: for builtins in general
16:56karolherbst: + we could run opts + scheduling over that later
16:57karolherbst: + don't have to calculate sched ops ourself
16:57karolherbst: what do you think about that?
16:59karolherbst: and it might be come in handy if we write our trap handler as well
16:59karolherbst: at some point
17:04imirkin: karolherbst: yeah, i looked at that list
17:04imirkin: karolherbst: i sent a thing to fix the surface ops too, last night
17:04karolherbst: yeah, I saw some patches
17:04imirkin: i thought i had told you about that issue already, but didn't see any patches from you
17:04karolherbst: I will look into that when at work tomorrow
17:05imirkin: yeah, whenever
17:05imirkin: the trap handler stuff is tricky
17:05karolherbst: ohh "gm107/ir: avoid using kepler instruction capabilities" yeah
17:05imirkin: but definitely doable. will require some fw changes.
17:05karolherbst: we talked about that, right
17:06karolherbst: totally forgot it
17:06karolherbst: imirkin: right, but I was more focusing on being able to write that stuff in nvir
17:06imirkin: it'd go in the library
17:07karolherbst: well right, but I would rather not write the library in assembly
17:07imirkin: and just gets programmed once
17:07karolherbst: but in nvir instead
17:07imirkin: yeahhhhh ... that'd be sorta nice.
17:07karolherbst: being able to write some little applications being able to generate binaries
17:07imirkin: definitely not compiled by nvir though
17:07imirkin: but something just fed directly into the emitter?
17:08karolherbst: I think we should go for being able to write applications against codegen
17:08imirkin: i dunno, maybe using function objects would work out
17:08karolherbst: this way we can pregenerate stuff
17:08karolherbst: also regenerarte when we make important changes
17:08karolherbst: or add new archs
17:08imirkin: thing is that the functions have to be at fixed offsets for multiple shaders to call them
17:08karolherbst: yeah, I saw
17:08imirkin: anyways, something for later :)
17:08karolherbst: well, I was thinking adding support for that before fixing fp64 for maxwell
17:09karolherbst: because with maxwell the assembly is completly different
17:09karolherbst: would have to touch every op
17:09imirkin: shouldn't take more than an hour
17:09imirkin: the sched codes being automatically computed is where it's a lot more valuable
17:10karolherbst: anyay, that's what I was thinking it would be nice being able to do that in nvir
17:10imirkin: anyways, i'll check out the layered rendering thing some time today
17:10imirkin: i didn't realize it was an issue on maxwell
17:10karolherbst: I think being able to write standalone apps would be kind of nice
17:10karolherbst: to just compile binaries and generate those lib/ files
17:11karolherbst: and before that I could move codegen out of the nouveau driver as well....
17:12karolherbst: which we need to do for vulkan anyway, which I probably or ben end up doing anyway
17:12karolherbst: probably me
17:43imirkin: yeah, i'm generally in favor of that. has to be done with some care though.
18:55imirkin: hm. ok yeah, this 3d thing is a bit annoying
19:18Yoshimo: It is not part of the nouveau wiki feature matrix so how well supported is the tegra x1 on linux?
19:19imirkin: it's a maxwell chip
19:20imirkin: nvidia modified nouveau sufficiently to operate with it
19:20imirkin: i've never personally tried it
19:22Yoshimo: does it suffer from all the problems we have with the desktop maxwell cards?
19:23imirkin: you mean reclocking? i think that could work, not sure.
19:23cyndis: tegra firmwares are released, and reclocking aiui happens through the soc clock tree which is implemented
19:24karolherbst: reclocking on maxwell is only an issue because you can't control the fans
19:24karolherbst: if there is no GPU fan, you are fine
19:24imirkin: karolherbst: X1
19:24imirkin: unrelated to the desktop issues.
19:24karolherbst: it needs some patches though
19:24imirkin: no vram, clocks are controlled differently.
19:25karolherbst: ohh right
19:25karolherbst: in that case, no patches needed really
19:25karolherbst: just something like that: https://github.com/karolherbst/nouveau/commit/448f122f145b2f31e62a7bf09d82a85cecd1fefc
19:25karolherbst: maybe it is already enabled for gm10b, no idea
19:25karolherbst: I am sure we have a static clock table for gk10a
19:26cyndis: gk20a, gm20b :)
19:26karolherbst: uhh, right
19:26cyndis: IIRC it was just working when I last tried (which was ages ago, dunno)
19:27cyndis: the primary difficulty for "normal" use is that the GPU has no display connector and this is not yet implemented in mesa, tagr is working on adding that
19:28cyndis: he probably can provide patches if asked
19:30imirkin: there's a "renderonly" helper which lets you merge things together
19:30cyndis: yeah, I think he's using that but I'm not too familiar with it
19:30cyndis: I just remember that the last them we tried to add that there was no such thing and everything was a mess
19:31imirkin: things haven't really changed much
19:31imirkin: i have a GK20A, but the board really hates it when there's traffic over ethernet
19:31cyndis: this was quite a long time ago
19:32imirkin: and it expresses this displeasure by hanging. so for my nfsroot setup ... not great :)
19:32cyndis: that is not optimal :)
19:33cyndis: thankfully TX2+ has really nice ethernet hw
19:33imirkin: it only developed this problem with time, so i think some driver did somethign bad with recent-er kernels
19:33imirkin: but it's easier to just power the thing off and leave it on a shelf
19:37Yoshimo: the nintendo switch has a x1 and people just got linux running so it was interesting to see how well the gpu runs on linux
19:37imirkin: generically, should work
19:38imirkin: practically, there's probably some setup work to make it happen
19:38cyndis: i'm wondering if we will get switch-related patches on linux-tegra
19:38cyndis: that would be fun
19:39Yoshimo: how far has the ps4 upstreaming come? Was the same team that got linux running
19:39imirkin: not sure i saw any upstreaming of the platform
19:41cyndis: i remember them talking about sending some gpu driver patches upstream in their ccc talk
19:43imirkin: but it's basically a whole new pc platform
19:43imirkin: arm has 100000 of them, but x86 isn't really set up for it
19:44cyndis: yeah, might be difficult
19:44imirkin: weird pcie bugs, etc
19:44imirkin: anyways, i never saw upstreaming efforts
19:44imirkin: perhaps i missed them
21:29bundito: Hey nouveau'ers... where can I start to look for why xrandr won't let me change resolutions? "Can't open display HDMI-1"
21:29bundito: Is it my new Nvidia card, or my headless HDMI adapter? (Note: I've used the headless adapter successfully with a different card)
21:38imirkin: what's a "headless HDMI adapter"?
21:39imirkin: either way, i have no clue what you're trying to do, so ... more info. please include dmesg, xorg log, and the exact command you're running that's failing in some way.
21:39skeggsb: [skeggsb@localhost nouveau]$ DISPLAY=HDMI-1 xrandr
21:39skeggsb: Can't open display HDMI-1
21:39skeggsb: would be my guess..
21:39imirkin: hehe, well that certainly wouldn't work particularly well.
21:50bundito: A headless adapater goes in the end of an HDMI cable and makes the card think there's an HDMI monitor connected.
21:50bundito: Trying to issue something like "xrandr --display HDMI-1 --output 1680x1050"
21:50imirkin: oh, ok
21:51imirkin: yeah, that won't work
21:51imirkin: you probably want --output
21:51imirkin: "man xrandr" may prove instructional.
21:51bundito: Did I type them backward again?
21:52imirkin: xrandr --output HDMI-1 --mode 1680x1050
21:52imirkin: or xrandr --output HDMI-1 --auto
21:52imirkin: display is the X display
21:52bundito: It *used* to work
21:52bundito: my kingdom for a terminal - one second
21:54bundito: I swear on a stack my old command used to work
21:55bundito: I wrote a shell script to issue it
21:55imirkin: xrandr --display sets the X display
21:55bundito: but --mode definitely worked
21:55imirkin: i.e. the name of the unix socket served up by the X server.
21:55bundito: I applaud you
21:56bundito: and HDMI dummy adapters are cool, and only about $8
21:56imirkin: what's the use?
21:57bundito: I work by remote, and my only physical monitor is an old 5:4 that tops out at 1024z768
21:57imirkin: still not sure what the use is.
21:57bundito: My MacBook Pro can show 1920x1200 easily
21:58bundito: Widescreen, higer resolution
21:58imirkin: but ... you can never see it
21:58bundito: I can, with NoMachine
21:58bundito: which mirrors what X11 puts out
21:58imirkin: oh. i never use that.
21:58imirkin: why not just use like Xvfb for arbitrary resolutions?
21:59bundito: Dunno. Got started with one and stuck with it.
21:59mupuf: rhyskidd: great! That's a first!