01:48 imirkin: booooo!
01:48 imirkin: why is handle 0 an invalid handle? :(
01:53 imirkin: ah right. and i should probably handle samplers coming from CONST, huh
02:17 imirkin: urgh.
02:17 imirkin: this bindless thing isn't extremely pretty =/
02:18 imirkin: esp if the same texture is both bound and bindless, we can end up unlocking that tic entry too early. grr.
02:18 imirkin: so now instead of it being a single-bit lock each entry needs its own refcount.
02:18 imirkin: URGH.
02:19 imirkin: maybe i can get away with just a second thing
02:40 imirkin: ok, looks like bindless basically works for textures
02:40 imirkin: now just need some copy-pasta to make images work
02:42 imirkin: oh hm.... probably won't be so easy =/
02:43 imirkin: on maxwell+, images use TIC id's, but on kepler it's a separate mechanism
03:15 imirkin: skeggsb_: in case you want to play with it: https://github.com/imirkin/mesa/commit/12ea51439d903011b66daeb1359db96cebb1b41c
03:15 imirkin: note that no images, and no compute. and VERY light testing.
03:16 imirkin: [and i could probably come up with a better name than 'lock2' ;) ]
03:28 skeggsb_: imirkin: cool, thanks, i'll have a play with it and see how it goes, maybe extend for images too
03:28 skeggsb_: btw, been writing a simple test against nvidia.. their texture handles aren't exactly what i'd expect if they were making it from tic/tsc index
09:01 hakzsam: imirkin: nice, you are working on bindless, does it work fine, at least for textures?
09:05 hakzsam: imirkin: well, the gallium interface can be changed if you want a real sampler object...
09:43 karolherbst: imirkin_: would you mind if I add a Base class for the NV*LoweringPass classes?
09:43 karolherbst: I want to move the handlePOW method into it
10:51 ArRay_: Hi, nouveau seems to make my computer crash randomly, sysrq keys don't work (so can't get kernel log), but it looks like vesa doesn't crash.
10:51 karolherbst: ArRay_: you could try to get some information through pstore, maybe SSH works as well
10:53 ArRay_: karolherbst: what is pstore ?
10:53 Tom^: ArRay_: and journalctl -b0 or -b1 doesnt show the error?
10:53 ArRay_: karolherbst: If it's only X crashing then I guess I could try ssh
10:53 ArRay_: Tom^: Doesn't seem to sync the kernel log
10:54 ArRay_: Tom^: Only get normal log and no reason to crash
10:54 ArRay_: Tom^: but the disk light is stuck
10:54 ArRay_: Tom^: I mean stuck off
10:55 karolherbst: ArRay_: https://github.com/abrt/abrt/wiki/pstore-oops
10:57 ArRay_: karolherbst: not sure how pstore works, but I'm running in legacy BIOS mode (on EFI motherboard)
10:57 karolherbst: uhhh
10:57 karolherbst: okay, then you get no pstore
10:57 karolherbst: on crash the kernel can write it's dmesg into pstore
10:58 karolherbst: and on EFI systems it gets stored inside efi
10:58 karolherbst: so you can read it out on next boot
11:00 ArRay_: karolherbst: ok, looks nice, but I haven't switched to EFI from BIOS yet, so don't know how easy it would be (I don't even have an EFI partition, because I reinstalled arch on an old ubuntu install because it was crashing too)
11:01 ArRay_: karolherbst: Well, I've never setup ssh either
11:01 karolherbst: ohh I see
11:02 ArRay_: but I guess it's easier to set up ssh than swithcing to EFI
11:02 karolherbst: problem is, the machine might not respond anymore
11:02 karolherbst: than ssh won't be any good
11:02 karolherbst: there is also netconsole
11:03 karolherbst: https://wiki.archlinux.org/index.php/Netconsole
11:03 ArRay_: karolherbst: I think too, since it doesn't sync to disk
11:03 karolherbst: netconsole is the way to go then
11:04 ArRay_: Well, I use a GTX 750 Ti with nouveau 1.0.15-1 on arch linux
11:04 ArRay_: I only see trying to do some kind of memory forensics but I don't know any tool for that...
11:04 ArRay_: karolherbst: I'll check netconsole
11:05 marmistrz: Hi! I came up with a (possible irrealistic ;) ) idea. We're still missing the compute and power management capability in nouveau and, as far as my impression is, it's not going to appear soon. But maybe we could reuse the parts of the binary nv driver where we don't have anything yet? For example, run nouveau as the main driver and when the user requests computing - delegate this to the binary driver or simply delegate everything to the binary
11:05 marmistrz: driver, until computing finishes.
11:06 marmistrz: What do you think?
11:06 marmistrz: s/possible/possibly/
11:06 karolherbst: won't work
11:07 marmistrz: why?
11:07 ArRay_: karolherbst: Do you think I need to use an ethernet port for netconsole ?
11:07 ArRay_: I mean, not wireless interface
11:07 karolherbst: ArRay_: not quite sure
11:08 ArRay_: I'll ask on #archlinux then ?
11:08 karolherbst: yeah
11:15 ArRay_: karolherbst: I'll try to reboot with nouveau and netconsole, to see if I can get the logs (it can take a while before it crashes through)
11:21 TiTan4T: hey
11:21 TiTan4T: I have a Lenovo T470p with Nvidia 940MX . I installed xf86-video-nouveau , lightdm and i3 . But I have problems while starting. The console says "nouveau: 0000:02:00.0: DRM: Pointer to flat table invalid"
11:22 Tom^: TiTan4T: if i were you i would install the nvidia binary
11:23 Tom^: TiTan4T: you wont have any reclocking on nouveau, meaning your card will run almost as slow as if you were software rendering everything on your cpu., you also have a maxwell which means binary firmware and a heap of other issues with nouveau.
11:23 karolherbst: Tom^: not on first gen maxwell
11:24 Tom^: isnt that the second gen?
11:24 Tom^: also i thought i still were in #archlinux
11:24 karolherbst: no
11:24 Tom^:facepalms
11:24 karolherbst: it's gm108
11:24 Tom^: it kind of makes sense for users to install nvidia blob in there, in here ofc. its simply just helpful bug hunting on any card
11:25 Tom^: my mistake :P
11:25 karolherbst: depends on what is important
11:25 karolherbst: on maxwell1 we get decent speed as well when clocked to highest states
11:25 Tom^: karolherbst: https://nouveau.freedesktop.org/wiki/CodeNames/ indeed i be dam, i thouth it was only the 7xx and 8xx that was first gen
11:26 Tom^: *thought
11:26 karolherbst: desktop
11:38 ArRay_: Just before I try, I forgot to say I use the linux-hardened kernel from arch linux, and I can't remember if it did with the grsec kernel (last versions)
11:40 ArRay_: anyway it works with vesa so it must be nouveau that would not work with the hardened kernel
12:02 Tom^: karolherbst: does the AC: ever change in the pstate to something like DC: if on a laptop and unplugged?
12:04 karolherbst: yes
12:05 Tom^: and the only states it has is AC: and DC: ?
12:05 Tom^: making a silly parsing of it :p
12:09 Tom^: if i understand this right https://github.com/karolherbst/nouveau/blob/master_4.11/drm/nouveau/nouveau_debugfs.c#L80 it seems it can be -- , too
12:09 karolherbst: maybe, never saw it
12:09 karolherbst: it's for unknown power sources
12:10 Tom^: mmh
12:14 Tom^: karolherbst: \o/ , ./nouveauctl -g , prints, core 1084 MHz memory 6999 MHz . now just to add this to my bottom panel in a widget. =D
12:15 Tom^: now just to get temps too.
12:16 karolherbst: I am nearly finished with my pow improvements, gives me +1.4% in pixmark_piano :)
12:17 Tom^: :o
12:18 Tom^: karolherbst: do you have your own fork for these things?
12:18 imirkin: karolherbst: you can put shared stuff into nv50_ir_build_util.cpp
12:18 Tom^: would be fun to tinkle with your experiments ;)
12:18 karolherbst: imirkin: I meant something like this: https://github.com/karolherbst/mesa/commit/fa462fd5118bbc9c5e6a479c3bdda11fcf321a1c
12:19 karolherbst: and handleWRSV is also a possible candidate, but there might be a bug in the nv50 version, because those differ in a way it looks like a bug
12:19 vpelletier: imirkin_: I think I finally understood the long comment on find_u4_magic_addr: instead of using the register dedicated to trigering MSI irq from pcie host to cpu, it is using another register which triggers another irq (for HT interrupts, but HT is not availabkle otherwise it would use another workaround). but shouldn't something rearm that irq ? so far I do not find it (and it may very well not be
12:19 vpelletier: needed, I still lack a lot in knowldge of what should happen)
12:20 imirkin: vpelletier: find benh_ :)
12:21 imirkin: karolherbst: i'd just as soon not have the base class. just have util functions.
12:21 imirkin: library vs middleware :)
12:21 karolherbst: yeah, true
12:22 karolherbst: anyway, I reworked my pow patch: https://github.com/karolherbst/mesa/commit/abf756e111641debdfeed373102187cabf47b5c1
12:22 imirkin: karolherbst: booo... didn't do it the automatic way? :(
12:23 imirkin: i thought you had that implemented
12:23 karolherbst: yeah, it was crappy
12:23 karolherbst: it gets way too complicated just for this
12:23 imirkin: BOOOOOO
12:23 karolherbst: and there is no point in doing it for other immediates
12:23 imirkin: BOOOOOOO!!!
12:24 imirkin: should be like ... a short function.
12:24 karolherbst: I thought so too
12:24 imirkin: i'll try to write it
12:24 karolherbst: but then things get complicate
12:24 imirkin: if it's longer than 20 lines, i'll admit defeat
12:24 karolherbst: you have to manage the values somehow
12:25 karolherbst: like try to write an algorithm which works for 16 and 9, but only produces 4 muls in the 16 case
12:30 karolherbst: imirkin: I guess in a functional language that's one line....
12:30 RSpliet: 80 char limit?
12:30 karolherbst: even then
12:30 imirkin: karolherbst: keep track of the powers of 2
12:30 imirkin: in an array
12:30 karolherbst: no, they just produce a chain of muls
12:31 imirkin: only do it for pow values that require a smaller total number of mul's
12:31 imirkin: than like ... 5
12:31 imirkin: or 6
12:31 karolherbst: there is no different in muls for 5, 6 or 8
12:31 karolherbst: *difference in amount of muls
12:31 imirkin: i meant 5 mul's
12:31 karolherbst: ohh
12:32 karolherbst: I think 4 is already too much
12:32 imirkin: well whatever
12:32 imirkin: some limit.
12:33 karolherbst: 7 needs 4 muls, that's more than 8, which needs 3
12:34 karolherbst: and if I do it for ^6, the gpr increase doesn't make it worth it
12:41 RSpliet: Yeah, it's non-trivial. Esp when you start considering stuff like n^15 = n^16 * (1/n)
12:43 karolherbst: n^(2^x - 1) is an asshole for x>=3 in every regard
12:44 imirkin: RSpliet: 1/x is too imprecise
12:45 RSpliet: oh yeah... discrete numbers
12:46 imirkin: could be fine for pow... dunno
12:46 karolherbst: RSpliet: well usually you do something like this: x^n = x^(2^a) * x^(n-2^a) and use the highest possible a
12:47 karolherbst: fun starts with n=15 or n=32
12:47 karolherbst: *n=31
12:49 karolherbst: imirkin: the beauty in functional programming is, that you just implement it for 0, 1 and 2 and then you map your pow call to a tree you build, because identical sub trees gets merged at runtime
12:51 karolherbst: 65 chars: (defun pow (a b) (do ((x 1 (* x a)) (y 0 (+ y 1))) ((= y b) x)))
12:53 karolherbst: recursive way 64 chars: (defun pow (a b) (cond ((= b 0) 1) (t (* a (cond a (- b 1))))))
12:53 karolherbst: *63: (defun pow (a b) (cond ((= b 0) 1) (t (* a (pow a (- b 1))))))
12:54 karolherbst: but maybe I find also a tree based solution
12:55 vpelletier: imirkin: benh_ mailed, you in CC
14:19 ArRay_: After checking kernel log it looks like I have an error coming from nouveau, but it doesn't make the system crash
14:24 hwnas: hi. are there any plans on fixing nouveau for nv40 and nv50 to work on recent desktops? Its useless at the moment. nv40 is competely crashing, nv50 create windows that jump around until you reboot
14:24 karolherbst: hwnas: creating bugs helps
14:25 hwnas: karolherbst: you mean bugreports? because the bugs are already there. thats why i report that here
14:27 ArRay_: "[ 7.601035] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 3e6684 [ IBUS ]" < that one
14:28 ArRay_:realized he forgot to send the log
14:30 hwnas: karolherbst: for example there is this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=98631
14:31 hwnas: this one: https://bugs.freedesktop.org/show_bug.cgi?id=96460
14:35 hwnas: should i flood the bugtracker with valid bugs? would that finally help? I am reporting this bugs about 2 years. nothing changed since then. one power management bug was fixed, patch was uploaded, and then it never got merged
14:39 hwnas: karolherbst: imirkin pinged that. still not merged: https://lists.freedesktop.org/archives/nouveau/2017-February/027290.html
14:41 hwnas: imirkin also get a nvidia 6200 pci card. also that didnt fixed anything till now. he got a pci card to not have to manually pull out his pcie card. he told that this would motivate him. probably it didnt
15:02 imirkin_: well, he's not looking anymore, but there are no plans to make nv30/nv40 drivers play better with the totally unreasonable demands placed by anachronistic software
15:45 Horizon_Brave: hi all
18:51 Lyude: karolherbst: does kepler not have SLCG?
18:54 karolherbst: dunno, never looked that deep into all this
18:55 Lyude: mupuf: ^
18:57 karolherbst: imirkin_: so should I simply add a "lowerPOW" method to BuildUtil? or did you have anything else in mind?
18:58 karolherbst: I kind of don't like to add tons of static functions where a build gets passed by reference. Maybe I should create a new class which is just a util class to help lowering stuff? Not quite sure yet
19:00 imirkin_: huh?
19:01 imirkin_: what's the problem?
19:01 imirkin_: [yes, add something to BuildUtil]
19:02 karolherbst: well just wondering because that class is mainly doing other things
19:02 karolherbst: well, it's still close enough though
19:03 karolherbst: imirkin_: also, could you look over my gallium_precise patches? You don't really need to push those, but I would feel more safe if you say it looks okay if I ask others to push those
19:05 karolherbst: most recent things are on my branch, I fixed one little bug I've added on the nouveau side, but this was a trivial thing. https://github.com/karolherbst/mesa/commits/gallium_precise
19:44 Lyude: mupuf: any idea if kepler is supposed to have SLCG?
20:56 karolherbst: oh no, they want to remove the geometry shader of doom :(
22:56 imirkin: skeggsb_: can i assume you haven't touched my patches?
23:09 skeggsb_: imirkin: only a little, not significant, been playing around with the binary driver instead :/