00:01 exidux: it definitely gets worse whenever applications use / used opengl for any type of rendering.
00:02 exidux: Also did a test compile of the out of tree to test if everything is set up correctly; Still needs some work.
02:01 karolherbst: mupuf: do you have some time? I want to discuss the pstate/cstate situation a bit on top of the vbios of nve7/kubast2
02:07 pmoreau: imirkin: When you hooked Kepler in demmt to print the kernel's code as CODE: with the output of envydis, you hooked Fermi as well right? (The code seems to support that, but just want to be sure.)
02:30 exidux: imirkin: I filed a bug for the ordeal. https://bugs.freedesktop.org/show_bug.cgi?id=92959
02:32 exidux: It is an ancient piece of hardware... heh. Setting eveything up to compile and work is rather slow and anoying on a machine without network cnnections.
07:13 imirkin: bonbons: hey, you had a nv1a right?
07:30 vixsomnis: Has anyone reported NV117 (GM107) / GTX 960M KMS not working (spams the boot log and crashes the system)? I'm on Arch Linux, but it's as issue for nouveau on Ubuntu also (and probably others).
07:31 vixsomnis: ( see: https://bbs.archlinux.org/viewtopic.php?id=204739; http://ubuntuforums.org/showthread.php?t=2301071 )
07:31 imirkin: ahaha, GM107's being branded as GTX 960? good job nvidia!
07:32 karolherbst: lol
07:32 karolherbst: imirkin: ohh no, this is right
07:32 karolherbst: imirkin: it is a laptop chip
07:32 imirkin: yeah, they pull this shit all the time
07:32 vixsomnis: Yeah, but that's not anything new.
07:32 karolherbst: 920M is even kepler
07:33 vixsomnis: They've been reusing the old architectures forever.
07:33 imirkin: vixsomnis: why is KMS even involved here?
07:33 vixsomnis: The laptop is optimus, but when nouveau does modesetting, everything crashes.
07:33 imirkin: aren't the screens attached to the intel chip?
07:33 vixsomnis: Yes, that's what I'm using right row
07:33 vixsomnis: *now
07:34 vixsomnis: But to boot, I have to nouveau.modeset=0
07:34 imirkin: nouveau shouldn't be setting any modes...
07:34 imirkin: oh, well that just disables nouveau entirely
07:34 karolherbst: vixsomnis: no no no, he was asking if the display is connected to the intel gpu ;)
07:34 imirkin: you mean there's an issue when nouveau loads?
07:34 imirkin: anyways, feel free to file a bug at bugs.freedesktop.org Xorg -> Driver/nouveau
07:34 vixsomnis: I was just checking to see if anyone's reported it yet
07:35 vixsomnis: It's a new laptop (XPS 15 9550!)
07:35 imirkin: not to my knowledge, but maxwell is a pile of fail all over.
07:35 imirkin: esp maxwell2, but also maxwell1
07:35 imirkin: although nothing that should be killing it on boot
07:35 imirkin: only on use :)
07:36 vixsomnis: Yeah, it's workable for now since I don't actually need it
07:36 vixsomnis: Intel to the rescue
07:36 karolherbst: vixsomnis: do you have a dmesg log somewhere?
07:36 vixsomnis: I'm not sure how to get the log, but I can try
07:36 vixsomnis: Can you get failed boot dmesg?
07:37 karolherbst: vixsomnis: I hope you understand, that your intel gpu is your _main_ gpu?
07:38 karolherbst: not performance wise, but it will be the one mainly used
07:38 vixsomnis: karolherbst: Yes, but the nouveau KMS driver still breaks stuff. The intel one works fine if I stop nouveau from loading.
07:38 imirkin: vixsomnis: unless there are screens connected to the nvidia gpu, you should just leave it disabled with nouveau.modeset=0 and move on with life
07:38 imirkin: and/or in the bios
07:39 karolherbst: vixsomnis: arch uses systemd, then you may want to check journalctl --boot -1 (or whatever boot you had nouveau crashing your system)
07:39 vixsomnis: Well, it'd be nice to have the nouveau driver working so I can use PRIME, and not bumbleebee/nvidia
07:39 vixsomnis: ( or at least try to configure it haha )
07:39 imirkin: for what?
07:39 imirkin: you'll get way worse perf than with the intel chip, in all likelihood
07:40 karolherbst: mhh reclocking doesn't work with mawell yet, right?
07:40 imirkin: that's the least of the troubles
07:40 karolherbst: I see
07:40 pmoreau: Don't you need the signed firmware for reclocking, anyway?
07:40 imirkin: actually i guess it's a good chunk of the troubles
07:40 imirkin: pmoreau: no
07:40 imirkin: pmoreau: GM107 is all fine
07:41 karolherbst: vixsomnis: what intel gpu?
07:41 vixsomnis: imirkin: If anything, so future people who purchase a laptop like this don't have to add kernel parameters just to boot into Ubuntu.
07:41 pmoreau: Oh right, GM107
07:41 vixsomnis: karolherbst: Intel is HD 530 (i7-6700K)
07:41 imirkin: karolherbst: the sched codes aren't being computed right now... we do a fairly pessimal thing (i think), so all shaders execute at a fraction of their potential perf
07:42 karolherbst: vixsomnis: let me put it that way: my intel HD 4600 is as fast as my nvidia gtx 770m at 0a pstate with nouveau (mid performance state)
07:42 karolherbst: imirkin: ohhhh
07:42 karolherbst: okay
07:42 imirkin: but clocks being low also doesn't help :)
07:42 karolherbst: and your 530 is maybe a little bit faster than the 4600
07:43 vixsomnis: I'm dual booting, so if I really need a fast GPU I'll just boot into Windows 10.
07:44 vixsomnis: I'll file a bug report once I can get the dmesg log. Thanks for the help
08:35 bonbons: imirkin: yes, nforce1 IGP
08:36 imirkin: bonbons: did you ever have issues with it?
08:36 imirkin: i mean... issues that remain unresolved
08:37 imirkin: i noticed some stuff that seemed wrong for both nv1a and nv1f, something to do with clocks
08:37 imirkin: when comparing the ancient xf86-video-nv code to the nouveau in-kernel code
08:38 bonbons: yes, it was missing DDC (though that's not directly nv1a issue) but rather IGP issue, for the rest, not used enough to be able to tell a lot about working (in the sense of acceleration)
08:38 imirkin: hm ok
08:39 imirkin: well DDC could conceivably be a clocks issue, but yeah, unlikely
08:43 bonbons: I guess it's a matter of finding out where it is (is it GPU part or otherwise just north-bridge), S3 was another issue where resume never worked as expected
08:43 bonbons: though it's some time ago I last tried out
08:45 imirkin: yeah, no worries... was just curious
08:50 bonbons: imirkin: no issue at that :) such requests are welcome
08:58 imirkin: bonbons: i might have a patch for you to test... but not soon
09:07 bonbons: imirkin: just ping me here, or better, by e-mail - currently rather busy not online that much
09:40 vedranm: I have GTX 970, running nouveau, and I have this issue
09:40 vedranm: https://bugzilla.redhat.com/show_bug.cgi?id=1224525
09:40 vedranm: When booting into Fedora 22 the X11 session is slow if not unresponsive and unusable. dmesg also contains a lot of errors relating to nouveau.
09:40 vedranm: this happens on Fedora 23 as well, even when using 4.3.0 from F24
09:41 vedranm: (I was hoping that rewrite from 4.3 will magically fix it)
09:41 vedranm: what info can I provide, what can I test to help debug this?
09:46 l1k: bonbons: about this gmux + vgaarb issue... I find it confusing that vgaarb touches gmux' I/O ports at all, can we somehow prevent it from doing that? it uses I think 256 bytes from 0x0700 upwards, is this part of some legacy VGA address space?
09:54 pmoreau: vedranm: You should open a bug report on bugs.freedesktop.org, under Product: xorg, Component: driver/nouveau, with a dmesg attached
09:54 pmoreau: vedranm: I guess the firmwares failing to load might be the cause
09:55 pmoreau: skeggsb: -^ You might have some good ideas on what's going wrong
09:56 pmoreau: Dunno if SELinux could be conflicting with the firmware upload?
09:57 vedranm: pmoreau: I can try booting with SELinux disabled
09:57 vedranm: is there any other options I could try_
09:57 vedranm: ?
09:58 pmoreau: Hum… I don't know, sorry :-/
09:58 pmoreau: I'll have a quick check at open bugs
09:59 vedranm: there is a bug that mentions nouveau.config=NvForcePost=1
09:59 vedranm: https://bugs.freedesktop.org/show_bug.cgi?id=89664
09:59 vedranm: for me, KMS works though
10:00 pmoreau: NvForcePost should not affect firmware loading AFAIK, but it can be a good option to try if you still have troubles even though firmwares were uploaded
10:04 imirkin: vedranm: note that you shouldn't expect any acceleration for a GTX 960
10:04 imirkin: vedranm: the bug you reference is for a 750 ti, which is entirely different
10:05 vedranm: imirkin: both are Maxwell, not_
10:05 vedranm: ?
10:06 imirkin: vedranm: both are nvidia too
10:06 imirkin: vedranm: and both manufactured on planet earth
10:06 imirkin: lots of similarities, but the big difference is that GTX 960 is a GM206 while 750 ti is GM170
10:06 imirkin: GM107*
10:31 pmoreau: The branch optimisation is less easier than what I thought, but I just realise I was also trying to get two different optimisations in one go.
10:37 bonbons: l1k: it seems so or it is handled that same way by hardware (maybe via firmware indirection)
10:43 vedranm: OK, found the reason why the firmware doesn't load
10:43 vedranm: the gm204/ directory is not there
10:44 vedranm: I have  ls /lib/firmware/nvidia/ │·························
10:44 vedranm: gk20a tegra124 tegra210
10:45 vedranm: same thing as on http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia
10:49 vedranm: pmoreau: can one download the firmware?
10:51 pmoreau: I had forgotten you had a 970… not sure which firmwares it is trying to load
10:51 pmoreau: I'll have a look
10:53 pmoreau: vedranm: Oh wait: you have a 970, so some gm20x card, right?
10:54 vedranm: pmoreau: I do
10:54 vedranm: it's trying to load gm204/fecs_inst.bin I think
10:54 pmoreau: So looking at the dmesg from bug report https://bugzilla.redhat.com/show_bug.cgi?id=1224525 might no help :-D
10:55 rewolff1: Hi. I'm experiencing very lousy performance in OpenScad. The OpenScad guys told me it might be related to syncing to VBLANK.
10:55 rewolff1: and yes: (==) NOUVEAU(0): GLX sync to VBlank enabled.
10:55 rewolff1: Is there a way to disable that? I tried: Option "GLXVBlank" "False"
10:55 rewolff1: to no effect.....
10:55 vedranm: pmoreau: you are right, I will add a note to this bug
10:55 pmoreau: vedranm: Could you upload your own dmesg somewhere please?
10:55 vedranm: pmoreau: I could, sec
10:57 pmoreau: rewolff1: Which card do you have? VBLANK should cap your framerate to the refresh rate of your monitor, so most likely around 60fps
10:57 rewolff1: Yes. GLXgears caps at around 6000 frames in 5 secs offscreen (where it starts up on my desktop setup) and 300 per 5 sec when onscreen.
10:58 pmoreau: rewolff1: I would rather suspect that you are running on a low clock
10:58 rewolff1: I agree fully with you that the 4-5 FPS i'm seeing should not be the result from syncing to the 60Hz frame rate.
10:58 pmoreau: Then vblank is most likely off, otherwise you would have 60fps, not 6000 on glxgears
10:58 rewolff1: The openscad process is, according to top, using about 10% of the CPU so it is WAITING for something.
10:59 rewolff1: The server reports:GLX sync to VBlank enabled.
10:59 vedranm: pmoreau: it's here http://pastebin.com/Sd04rJif
10:59 pmoreau: rewolff1: Which card do you have?
10:59 pmoreau: vedranm: Thanks!
11:00 rewolff1: and it runs at 60fps when onscreen, and I can set an environment variable to get it to 1200 fps (6000/5 sec) That all works. ... But not on openscad.
11:00 rewolff1: card.. justasec.
11:00 rewolff1: 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
11:00 rewolff1: Does that tell you enough?
11:01 pmoreau: Fermi doesn't have reclocking, so you're most likely stuck on the lowest clock
11:01 pmoreau: Which won't give you much performance
11:02 rewolff1: Is "the 1200 FPS" for glxgears "lousy performance" nowadays?
11:03 pmoreau: I think you can easily reach a few 10k fps on Kepler IIRC
11:04 pmoreau: What is the env var to disable vblank?
11:04 rewolff1: I don't expect the best, I have a cheap card (with the argument that what I had 5 years ago was sufficient, so a cheap card NOW should be much better than what I had). I have it passively cooled. So it's not state-of-the-art. But on my previous CPU with my previous video card I had "reasonable" behaviour.
11:04 pmoreau: (Just to test on my old laptop, which has reclocking)
11:04 rewolff1: vblank_mode=0
11:05 rewolff1: (in bash export vblank_mode=0
11:05 rewolff1: for me in tcsh setenv vblank_mode 0 )
11:05 pmoreau: I have 1800fps on a MCP79 (which is an integrated GPU from 2009, Tesla), on lowest clock
11:06 rewolff1: 8205 frames in 5.0 seconds = 1640.874 FPS
11:06 rewolff1: Not bad.
11:06 rewolff1: So I get 88% of what you get. Sounds fine by me.
11:06 pmoreau: But on highest clock, you could get like 4x that
11:07 pmoreau: (sorry, I had 370fps on lowest, 1200fps on highest)
11:07 rewolff1: I'm not interested in "great" performance. The fact that this card is "quiet" is important to me as well.
11:08 pmoreau: Do you have nouveau.pstate=1 on your command line?
11:08 rewolff1: The fact that openscad is only using 11% CPU while it is still seconds behind refreshing the screen for my mouse movement means something else is going on.
11:08 pmoreau: It could be that you're limited by memory clock on the GPU
11:08 rewolff1: Kernel commandline ? Don't think so.
11:09 rewolff1: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=UUID=1bf2d530-c709-4cd6-9048-ab7aa16135e0 ro quiet splash vt.handoff=7
11:09 pmoreau: Currently, it won't allow you to reclock your card, but you might have a look at the different performance levels.
11:10 rewolff1: There is something odd with openscad: it buffers the mouse movements, renders every frame of the "drag" and can easily lag by many seconds.
11:12 rewolff1: I don't think it's a pure-graphics-performance problem, as a card on a 5 year old computer did much better and I'm gettin reasonable perorrmance out of "glxgears".
11:12 rewolff1: it's a software-interaction somehow.
11:13 rewolff1: A computer with: Release Date: 06/20/2006
11:13 rewolff1: 01:00.1 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV280 [Radeon 9200 PRO] (Secondary) (rev 01)
11:13 rewolff1: is MUCH snappier.
11:13 rewolff1: (but it might slow down as well if the software were upgradded to ubuntu 15.10/recent openscad).
11:14 pmoreau: vedranm: I can't find any firmware file for gm20x, and I don't think there are any apart from the ones NVIDIA said they would release.
11:14 vedranm: pmoreau: and they did not?
11:15 pmoreau: vedranm: We are still waiting. :-) They released the code for loading the firmwares on Tegra, but it is not enough for desktop cards. And the firmwares are still missing
11:16 vedranm: OK, I see
11:16 pmoreau: rewolff1: I guess you don't have any errors in your dmesg, about some slowpath or some timeouts, or other stuff?
11:16 vedranm: so, once we get that firmware, one will hopefully have stable modestting?
11:16 vedranm: but not 3D?
11:17 pmoreau: I thought you could already have modesetting with recent kernels, but maybe something's missing for your card.
11:17 rewolff1: Nothing exccept an USB device connect for the last two days.
11:17 vedranm: pmoreau: actually, you are right, KMS works
11:18 vedranm: but GDM is extremely sluggish, and I am not talking software rendering level sluggish
11:18 vedranm: like takes 20 seconds to play fadeout/fadein animation
11:19 vedranm: so fixing that would require firmware from NV or 3D support?
11:19 pmoreau: 3D support requires firmwares from NVIDIA as well
11:20 rewolff1: http://www.phoronix.com/scan.php?page=news_item&px=MTcyNjQ
11:20 rewolff1: tells me that I can do: Option "GLXVBlank" "False"
11:20 rewolff1: or "Off", but I don't see a difference (neither in the X startup log or in performance).
11:21 vedranm: pmoreau: OK, waiting on it then
11:21 rewolff1: Where would such an option go? I put it in: /usr/share/X11/xorg.conf.d, in a file called 90-nosync
11:21 vedranm: pmoreau: just one more question, please
11:21 pmoreau: rewolff1: I have no idea, sorry. Please open a bug report, or maybe somebody else here will have a better idea.
11:21 vedranm: the guy from RH bugzilla has this issue
11:21 vedranm: [ 1.725945] nouveau [ PGR][0000:01:00.0] using external firmware
11:21 vedranm: [ 1.725958] nouveau 0000:01:00.0: Direct firmware load for nouveau/nv117_fuc409c failed with error -2
11:21 vedranm: [ 1.725963] nouveau 0000:01:00.0: Direct firmware load for nouveau/fuc409c failed with error -2
11:21 vedranm: [ 1.725965] nouveau E[ PGR][0000:01:00.0] failed to load fuc409c
11:21 vedranm: so 750 Ti has some kind of nouveau firmware?
11:22 pmoreau: Yes, it has firmwares for acceleration at least
11:23 pmoreau: Which was added in 4.1
11:24 vedranm: that's kernel 4.0.4 that he is using
11:25 vedranm: OK
11:25 vedranm: thanks a lot
11:25 pmoreau: Updating might help
11:25 vedranm: and let's hope nvidia delivers something
11:25 pmoreau: It would be nice :-)
11:25 vedranm: I was actually worried that my 970 is some kind of crappier edition
11:26 vedranm: so, thanks for clarification of that as well
11:51 rewolff1: ok. I installed Ubuntu 14.04, used the openscad from there, and..... get reasonable (but not great) performance out of my RUNNING X-server. Not a driver problem.... (it could still be that there is too much wait-for-vsync going on that is simply not implemented in the older version of openscad and the libraries in 14.04).
11:51 rewolff1: Anyway, pmoreau, thanks for your help. :-)
12:50 vedranm: pmoreau: tried booting 4.2.6, interesting result
12:50 vedranm: [ 9.299143] nouveau [ PGRAPH][0000:02:00.0] using external firmware
12:50 vedranm: [ 9.792016] nouveau 0000:02:00.0: Direct firmware load for nouveau/nv124_fuc409c failed with error -2
12:50 vedranm: [ 9.792053] nouveau 0000:02:00.0: Direct firmware load for nouveau/fuc409c failed with error -2
12:50 vedranm: [ 9.792061] nouveau E[ PGRAPH][0000:02:00.0] failed to load fuc409c
12:50 vedranm: so, 4.2.6 expects nouveau (open?) firmware, and 4.3 expects nvidia one?
12:51 RSpliet: vedranm: nouveau does not expect any fuc firmware files unless you specify otherwise in your kernel parameters
12:51 vedranm: RSpliet: I am using the default Fedora kernel
12:52 RSpliet: vedranm: paste a full dmesg on fpaste.org
12:54 vedranm: RSpliet: http://fpaste.org/290852/
12:54 vedranm: RSpliet: ignore the radeon part, I have two cards in my machine
12:55 RSpliet: as yes, GM204; I don't think we'll support that with open firmware
12:55 RSpliet: ever
13:01 vedranm: RSpliet: so, 4.2 had the wrong assumption?
13:02 RSpliet: I'm not too farmiliar with Maxwell cards myself, but I think the "assumption" you refer to does not make a lot of difference
13:03 RSpliet: given how nouveau's firmwares are compiled into the driver itself
13:03 RSpliet: whereas external (eg. closed source) firmwares must be loaded from the filesystem
13:03 vedranm: RSpliet: I am aware of that
13:03 RSpliet: possibly the directory changed between 4.2 and 4.3, but that's a trivial change
13:04 vedranm: OK
13:06 RSpliet: but honestly, going through the 4.3 changelog I see no mention of a directory change between 4.2.6 and 4.3
13:09 vedranm: RSpliet: could be something on Fedora's side?
13:11 vedranm: in any case, it does not matter much if nouveau firmware will not support 970 and we are stuck with wating on nvidia
13:11 RSpliet: indeed, sorry
13:12 vedranm: RSpliet: no need to be sorry, the work that you guys are doing is monumental
13:12 vedranm: just read pmoreau's blog post on CUDA/OpenCL and all that needs to be done
13:12 RSpliet: oh, he has a blog? cool!
13:13 RSpliet: yeah, I wish I had some serious time to contribute these days
13:13 vedranm: RSpliet: https://blog.pmoreau.org/post/nouveau_towards_opencl/cuda_support_initial_progress/
13:13 pmoreau: vedranm: Really?! Didn't know anyone had read it, apart from Samuel :-D
13:13 pmoreau: vedranm: It is definitely not up-to-date
13:13 vedranm: pmoreau: I googled you, wanted to know what's your background
13:13 pmoreau: :-D
13:13 pmoreau: Big Brother is Watching you!
13:14 pmoreau: I still need to fix that certificate issue
13:14 vedranm: yeah, actually, I am curious how people start to hack on radeon/nouveau
13:14 pmoreau: My laptop was not working with Nouveau, so… I jumped in
13:14 vedranm: I teach at a uni and my students certainly aren't excited by that possibility
13:15 pmoreau: :-/
13:15 pmoreau: I guess you are teaching in computer science?
13:15 vedranm: pmoreau: I am
13:15 vedranm: we have a course on CUDA
13:16 pmoreau: Right, I can understand that philosophy students might not be tempted by RE'ing drivers. :-)
13:16 pmoreau: Nice!
13:16 vedranm: each year while I teach I tend to try the open source stack (OpenCL/libclc/LLVM/Mesa/Gallium3D/Clover/radeon-or-nouveau)
13:16 pmoreau: I doubt they'll use CUDA on Nouveau any time soon
13:16 vedranm: pmoreau: indeed
13:17 pmoreau: OpenCL might have a chance
13:17 vedranm: they tend to think of this stuff from a user's perspective
13:17 vedranm: exactly
13:17 pmoreau: :-D
13:17 vedranm: this year it worked for the first time
13:17 pmoreau: "It doesn't work: that software/driver sucks!"
13:17 vedranm: I had mesa from Debian experimental, I think
13:17 vedranm: 11.0+
13:17 vedranm: and Radeon 6450
13:17 pmoreau: Cool!
13:17 vedranm: and vector of 0 + vector of 0 = vector of 0
13:18 vedranm: yeah, so I got excited
13:18 pmoreau: That I should be able to do as well!
13:18 vedranm: pmoreau: so, nouveau can sum zeroes?
13:18 pmoreau: Upstream Nouveau, no
13:19 pmoreau: But I have been hacking on SPIR-V since that blog post, and now I can do adds and storing thread ids into a vector, so summing vectors should work
13:19 vedranm: pmoreau: wow!
13:19 pmoreau: On Tesla
13:19 vedranm: crap, we have Fermi
13:19 vedranm: so, you have the full stack going?
13:20 pmoreau: Fermi+ needs some changes, as inputs are stored in a const buffer rather than shared memory, and pointers are 64-bit rather than 32-bit.
13:20 vedranm: that is, could I use pycuda/pyopencl and have open source stack all the way down to hardware
13:20 pmoreau: Oh no! You need to generate by hand the SPIR-V for each kernel, as there is no compiler yet from OpenCL to SPIR-V :-D
13:20 vedranm: pmoreau: is this info public or is it reverse engineered?
13:21 vedranm: I see
13:21 vedranm: interesting!
13:21 pmoreau: How inputs are stored? I traced the binary driver to get that, but maybe you can find that info on the CUDA webpage, either programming guide or tuning guide?
13:22 vedranm: I tend to doubt that
13:22 vedranm: maybe parts of it are scattered around
13:26 hakzsam: imirkin, got bin/gl-2.0-edgeflag -auto working on nv50 :)
13:27 hakzsam: and bin/point-vertex-id
13:57 imirkin: hakzsam: oh nice! you copied the nvc0 bits?
13:57 imirkin: and ideally adapted them in a refactorable way?
13:58 hakzsam: imirkin, somehow, yes
13:58 imirkin: hakzsam: awesome :)
13:59 hakzsam: imirkin, I'll first make a patch which *only* fixes that edgeflag stuff in order to backport it to mesa-stable, but I could make other ones to factorize the code a bit if you want :)
13:59 imirkin: hakzsam: dunno if it's worth a stable backport
13:59 imirkin: but if you want
13:59 hakzsam: okay
14:04 imirkin: hakzsam: it's impressive if you really got it to work well... there's a lot of subtlety in that logic. look forward to reviewing :)
14:05 imirkin: i was always afraid to touch it
14:05 hakzsam: imirkin, the patch is not ready yet, still need to make sure I don't break anything else first :)
14:06 imirkin: hakzsam: blender might use edge flags... at least old versions probably did
14:06 hakzsam: okay
14:06 imirkin: hakzsam: i also need to finish my nv50 interpolation work... i got it to semi-work, but in practice it caused breaking more stuff than it fixed
14:07 hakzsam: what things did you break?
14:07 imirkin: the blender trace that i was trying to fix :)
14:07 hakzsam: hehe :)
14:08 imirkin: like it's a tiny bit broken now, but it became *really* broken :)
14:10 imirkin: basically i was trying to fix shade model = flat
14:12 hakzsam: well, bin/gl-2.0-edgeflag-immediate doesn't work, my fix is really not ready :)
14:13 imirkin: the edgeflag attrib might be a float or int
14:13 imirkin: check the (updated) nvc0 logic
14:13 hakzsam: okay
14:16 imirkin: hakzsam: i guess you understand what's going on though right?
14:17 imirkin: hakzsam: i mean the overall idea of how (idiotic) the edgeflag thing is?
14:18 hakzsam: I read the spec about that but I don't really know what is going on behind this edgeflag stuff to be honest
14:18 imirkin: so...
14:18 imirkin: normally you tell it to draw some vbo
14:18 imirkin: from this index to that index
14:18 imirkin: (or you give it an index buffer)
14:18 imirkin: however for the f*cking edgeflag, you can't feed it from a vertex attribute
14:19 imirkin: so you have to *manually* flip it with your bare hands
14:19 imirkin: so instead of telling it to draw vertices 1..10000000
14:19 imirkin: you manually scan the edgeflag, and if it flips at, say, vertex 3
14:19 imirkin: you tell it to draw vertices 1..2
14:19 imirkin: then flip the edge flag
14:19 imirkin: then draw vertices 3..n
14:19 imirkin: then flip the edge flag
14:19 imirkin: etc
14:20 imirkin: as for what the edge flag does... it's even dumber.
14:20 hakzsam: that makes sense regarding the code and the MMT trace of the blob
14:20 imirkin: basically you might have some higher-order primitive
14:20 imirkin: like, say, a polygon, or even a mesh
14:20 imirkin: but when you draw it in "line" mode (i.e. not fill) you don't want all the inner tri's to actually be visible
14:20 imirkin: so you can tell it which lines should be visible and which shouldn't
14:20 imirkin: by attaching an edge flag to a vertex
14:21 imirkin: and only the lines are drawn where both vertices have edge flags? or something like that.
14:21 imirkin: or only between sequential vertices when the edge flag is on
14:21 imirkin: yeah, that makes more sense.
14:21 hakzsam: okay, I see
14:22 imirkin: i forget how/why primitive restart plays into this... but for some reason it does on nvc0
14:22 imirkin: i think calim redefined the meaning of the indices in the index buffer? something like that.
14:23 imirkin: primitive restart = interrupt primitive when hitting vertex index N
14:23 imirkin: so it'll break a tristrip, for example
14:25 hakzsam: thanks for your explanations, this is going to help me to correctly fix that issue
14:36 pmoreau: imirkin: How do you enable the carry flag on an FMA operation, on Fermi+ cards?
14:37 pmoreau: I had a look at emitFMAD, but couldn't figure it out
14:37 imirkin: what do you mean 'how'?
14:37 imirkin: you flip a bit i assume?
14:38 imirkin: might not be possible
14:38 pmoreau: Right, but when you create the instruction, how do you specify that you want that bit flipped?
14:38 imirkin: er wait, what do you mean by 'the carry flag'?
14:38 imirkin: that makes no sense for FMAD
14:38 pmoreau: Trying to get implement the following:
14:38 pmoreau: 00000080: 80009c03 20078000 add $r2 $c (mul u32 $r0 u32 $r3) c0[0x20]
14:38 pmoreau: 00000088: 9000dc43 20868000 add $r3 (mul high u32 $r0 u32 $r3) c0[0x24] $c
14:38 imirkin: that's integer
14:39 pmoreau: That's not wrong! --"
14:39 imirkin: it's not FMA, it's MAD
14:39 imirkin: anyways
14:39 imirkin: what is for? 64-bit mul? that's magically taken care of
14:39 pmoreau: It's getting late…
14:40 imirkin: take a look at split64bitops
14:40 imirkin: pmoreau: BuildUtil::split64BitOpPostRA
14:40 imirkin: that gets run post-ra (as you might imagine)
14:40 pmoreau: I went with a straight 64-bit first, but it never got split. Though I probably did a ton of things wrong, which might explain why it wasn't split.
14:41 imirkin: probably... let me see your code.
14:41 imirkin: also i dunno if that 64-bit splitting is hooked up for nv50
14:42 imirkin: also not all ops are magically split for 64-bit... only the ones that were necessary. mad/fma might not be hooked up.
14:43 pmoreau: It's for Fermi+
14:43 imirkin: hm so actually this is a 32x32 + 32 -> 64 right?
14:43 imirkin: or rather, 32x32 + 64 -> 64
14:44 pmoreau: Kind of, except the 64 from the + 64 is stored as two 32
14:45 imirkin: sure, but that's a logical 64-bit int
14:45 imirkin: there are no 64-bit integer ops on nvidia isa
14:49 pmoreau: It's a physical 64-bit int (a pointer in my case), not sure what you mean by logical
14:51 imirkin: i mean it's a 64-bit int, doesn't matter how it's stored
14:51 pmoreau: Ok
14:51 imirkin: so logically you want mad with 32-bit multiplicative operands + 64-bit additition
14:51 pmoreau: Right
14:52 imirkin: i.e. 32x32 + 64 -> 64
14:52 imirkin: split64BitOpPostRA doesn't handle that. but it could.
14:53 pmoreau: I'll have a look there, thanks!
14:53 imirkin: could easily teach it about mul/mad
15:08 pmoreau: In BuildUtil::split64BitOpPostRA, `lo->setDef(1, carry);` should be `lo->setFlagsDef(lo->defCount(), carry);`
15:09 imirkin: no.
15:09 pmoreau: At least it is consistent with the following operation on the hi part, and the ouput of envydis does place the flag correctly (which was not the case with the previous code)
15:09 imirkin: the only thing it needs is MAD handling in the top portion
15:09 imirkin: er actually, i guess there's more to it
15:09 imirkin: since you need to copy the mul args in
15:09 imirkin: and set the hi bit
15:09 imirkin: (which is a subop iirc)
15:10 pmoreau: I'll look at that
15:11 pmoreau: But yeah, I realise something was missing as all args on the second mad where all 0x0 for the mul.
15:11 imirkin: right
15:11 imirkin: if (lo->getSrc(s)->reg.size < 8) {
15:12 imirkin: that's the bit you want to change
15:12 imirkin: for MAD
15:12 imirkin: and MUL
15:12 pmoreau: I was looking at it :-)
15:27 pmoreau: I still continue to believe that the carry should be put as a defflag rather than a def on the lo operation
15:27 imirkin: you're mistaken.
15:28 pmoreau: Well then something else in the pipeline is wrong, cause if it is set as a def, it isn't present in the generated code
15:29 imirkin: probably an error in the emitter
15:31 pmoreau: IMAD looks at the def flag for setting the carry bit
15:33 imirkin: ah :) i can see why you would have thought that then
15:33 imirkin: look at e.g. IADD
15:33 imirkin: and double-check the gk110/gm107 emitters as well
15:34 pmoreau:looks
15:35 imirkin: if (i->defExists(1))
15:35 imirkin: code[1] |= 1 << 26; // write carry
15:35 imirkin: hmmmmm
15:35 imirkin: wait, you might be right... flag might be the carry
15:36 imirkin: pmoreau: yeah. my bad.
15:37 pmoreau: No problem :-)
15:38 pmoreau: It made more sense to me, that if it was a flag as an input, it would be a flag as an output as well
15:39 imirkin: looks like the gk110 emitter doesn't handle it for imad
15:40 imirkin: it doesn't seem like there's a ton of consistency around whether it's a flag def or not
15:41 pmoreau: :-D
15:41 pmoreau: All the more confusing, the better!
16:04 pmoreau: This first version seems to work for my test case at least. Will need to clean everything before submitting for review
16:12 imirkin: cool!
17:44 derstrom: Hi. I'm testing out Debian Unstable (using Linux Kernel 4.2.x), and every time I execute "glxinfo | grep renderer", gnome-shell crashes, leaving me with a cursor to move freely and the desktop wallpaper. Where do I need to look specifically to find the logs that can help in a bug report about this issue? Thanks.
17:45 derstrom: I have a NVIDIA card, so I am assuming this issue is somewhat relevant.
18:07 skeggsb: win 18
18:07 skeggsb: gah
18:56 simonpatapon: hi
18:56 simonpatapon: i'm trying quad monitor with an intel onboard i915 and Geforce 560TI
18:58 simonpatapon: lspsci : http://pastebin.com/kuXS9TEB /etc/X11/xorg.conf : http://pastebin.com/Erw4fGc0 xlog http://pastebin.com/q69pZ81U
18:59 simonpatapon: just saying same results on nouveau and nvidia
18:59 simonpatapon: so surely a conf issue
19:07 simonpatapon: so surely a conf issue
19:31 imirkin: simonpatapon: two issues -- #1, your libglx.so is left over from a blob install. issue #2 - get rid of the device sections in your xorg.conf
19:32 simonpatapon: imirkin: both sections?
19:32 imirkin: simonpatapon: take a look at the info at http://nouveau.freedesktop.org/wiki/Optimus/ for how to set up secondary screens with reverse prime
19:36 imirkin: simonpatapon: gtg, good luck