00:43 imirkin_: skeggsb: check out https://bugs.freedesktop.org/show_bug.cgi?id=99372 :)
00:43 imirkin_: the bug that will not die.
00:46 mangix: are nouveau kernel crashes to be reported?
00:55 whompy: Btw, way off topic now, but you can generate single application passwords in the Google account page for two factor Auth for legacy stuff.
00:55 whompy: I believe that worked last time I tried.
00:56 whompy: They do tend to drop stuff like that rather randomly and quietly though.
00:58 mangix: if i have a bug report for a kernel crash, do I post it under Xorg/Drivers/Nouveau?
01:16 imirkin: mangix: sure, but i wouldn't necessarily file a bug report... briefly mention what info you have
01:16 imirkin: most crashes are unactionable
01:26 mangix: basically
01:27 mangix: get epiphany, visit https://www.google.com/chrome , and cry
01:27 mangix: firefox and chrome have no problem with that webpage
01:28 imirkin: good one.
01:28 mangix: ?
01:28 imirkin: i'm guessing https://bugs.freedesktop.org/show_bug.cgi?id=99373 is you?
01:28 mangix: yeah
01:29 imirkin: maybe it's trying to tell you something - keep using epiphany, don't switch to chrome ;)
01:29 mangix: LOL
01:29 mangix: too bad epiphany is slow
01:29 mangix: the reclocking situation doesn't help either
04:09 nyef: ... I must have the weird 3D displays or something. On my big 3D panel, none of the FP modes work (they display something, but it's wrong), and one of the two 1920x1080i SBSH modes doesn't always produce a usable display.
04:11 nyef: Okay, it's not just the 1820x1080i SBSH modes that can produce an odd single-tone image, just got it from one of the 1280x720 modes (not sure which one).
04:11 nyef: s/1820/1920/
04:18 nyef: I have a couple of things that I want to tweak on the HDMI InfoFrame sequence, but I'm currently thinking to send the patches to the nouveau list mid-Friday with a prefactory message that basically says what I know to be incomplete and/or wrong with them.
04:22 nyef: Oh, *hell*. I see what's going on with those bogus modes.
04:23 nyef: Someone interpreted "shall support transmission for at least one of" as "shall support transmission for all of".
04:39 nyef: And that's one rough edge filed off, provided that it actually works properly.
05:03 nyef: ... I'm getting an occasional screen of solid color after changing modes. It's almost predictable (seems that running "testdisplay -3" after a reboot always causes it when enabling the 1920x1080i mode, but running it a second time the effect occurs on different modes, sometimes with different colors).
05:04 nyef: This on my MCP89 system.
07:53 tacchinotacchi: so I have this MMIO dump and I wanted to use envydis on the SEQ script
07:54 tacchinotacchi: I grep for lines containing PDAEMON.DATA, sed everything but the stored value away, I'm left with a succession of hex values
07:55 tacchinotacchi: and I used envydis on that, but there seem to be a lot of unknown instructions
07:55 tacchinotacchi: is there a better way?
09:23 pmoreau: tacchinotacchi: Did you use the correct flags to specify for which GPU it should interpret it? And I am not entirely sure envydis is the program to run on the SEQ script (though I could be wrong).
09:24 tacchinotacchi: I'm not sure I'm using it on the correct part of the log
09:25 tacchinotacchi: before SEQ script, size: 496B
09:25 Celelibi: Looks like nouveau provoke soft lockup bugs.
09:25 tacchinotacchi: there's a lot of PDAEMON.DATA[0] <= *
09:25 Celelibi: I intend to use the nvidia driver, but if you're interested I can run a few tests some times.
09:26 tacchinotacchi: I'm taking all those *s, and running ./envydis -m falcon -V fuc3 -i
09:26 pmoreau: Celelibi: Could you provide the output from dmesg please?
09:26 tacchinotacchi: fuc3 because my card is an nvc1
09:27 pmoreau: Could be… I have never played with SEQ scripts :-/
09:27 pmoreau: Is that the SEQ script from NVIDIA or Nouveau?
09:27 tacchinotacchi: Nvidia
09:28 pmoreau: Hum… sorry, no idea.
10:07 Celelibi: pmoreau: not now, but I'll try to paste it.
10:07 Celelibi: Meanwhile, here is the message that used to pop on every console: "NMI watchdog: BUG: soft lockup - CPU#1 stuck for *s! [kworker:*]"
10:08 Celelibi: Probably not very informative.
11:09 karolherbst: tacchinotacchi: the SEQ block is the parsed script. the PDAEMON DATA block won't help you much
11:10 karolherbst: sadly we have no parser for the nouveau scripts
11:10 karolherbst: you can dump what nouveau does with nouveau.debug=pmu=debug I think, or =trace
11:11 karolherbst: but you would have to parse this by hand, which isn't that hard, but it would be nice to have a tool for that
11:11 tacchinotacchi: isn't the SEQ script sent to the gpu ( ideally ) the same?
11:21 karolherbst: no
11:21 karolherbst: the SEQ script is parsed by the software running on the PMU
11:21 tacchinotacchi: exactly
11:21 karolherbst: which we wrote ourself and only understands nouveau format
11:22 tacchinotacchi: so it's our job to upload an os to the PMU?
11:22 karolherbst: so there are two options: 1. write a parser for nouveaus SEQ scripts oder 2. change nouveau to accept nvidias format
11:22 karolherbst: we already have software on the PMU
11:22 karolherbst: the format of the script is just differently
11:23 pmoreau: karolherbst: If I’m not mistaken, tacchinotacchi was looking at the NVIDIA SEQ script, not the Nouveau one.
11:23 karolherbst: yeah sure
11:24 karolherbst: but if you want to figure what nouveau is doing wrong it makes sense to compared the nvidia one with the nouveau one
11:24 karolherbst: or you just read the code and figure the crap out yourself, which is a super silly idea
11:24 karolherbst: and a waste of time
11:24 tacchinotacchi: they are both readable by the same PMU, right_
11:24 karolherbst: tacchinotacchi: there is firmware running on the PMU
11:25 karolherbst: tacchinotacchi: nvidia uses theirs, which only understands the nvidia SEQ format, and nouveau runs its own, with its own SEQ script format
11:25 pmoreau: Right, but the initial question was how to properly parse the NVIDIA one, as envydis was returning a lot of unknown instructions
11:25 karolherbst: tacchinotacchi: drm/nouveau/nvkm/subdev/pmu/fuc/memx.fuc
11:25 tacchinotacchi: I see
11:26 tacchinotacchi: pmoreau: my mistake, as usual
11:26 karolherbst: pmoreau: the SEQ script dumped by demmio is already parsed
11:26 tacchinotacchi: I was supposed to look *after* the "SEQ script" line, not before
11:26 karolherbst: ohh right, I could have told you this
11:26 karolherbst: partly my mistake then
11:26 tacchinotacchi: my confusion came from the fact that it sends a lot of data to PDAEMON before of the script
11:27 tacchinotacchi: my fault for sending a message before trying the most straightforward solution
11:29 karolherbst: tacchinotacchi: the SEQ script is inside that PDAEMON thing
11:29 karolherbst: but demmio is so nice and parses that for you
11:29 tacchinotacchi: changing mem underclock from -100 to -200, nothing changes after the "SEQ script" line
11:29 tacchinotacchi: 0 to -100 changes one value in the script
11:29 karolherbst: mhh
11:29 karolherbst: interesting
11:30 karolherbst: I don't know how it works on fermi
11:30 karolherbst: but on kepler the clocks are also set within the scrupts
11:30 karolherbst: *scripts
11:30 karolherbst: tacchinotacchi: don't forget that you have multiple SEQ scripts there
11:30 tacchinotacchi: I will delete the dumps and carefully label the new ones
11:30 karolherbst: so you somehow have to check which is the right one
11:30 tacchinotacchi: yes, exactly what I said
11:31 tacchinotacchi: I will be more careful in inserting markers
11:31 karolherbst: okay :)
11:32 tacchinotacchi: oh, and I will make sure nvidia-settings doesn't just ignore me .-.
11:45 Celelibi: pmoreau: Here is my kern.log https://paste.debian.net/908398/
11:45 Celelibi: The messages are mostly repeating.
11:45 Celelibi: The lockedup task might vary.
11:45 pmoreau: Thanks, I’ll have a look
11:47 pmoreau: Celelibi: Do you have the full log available?
11:47 pmoreau: And do you get those soft lockups if the system/NVIDIA card does not go to sleep?
11:48 Celelibi: It didn't go to sleep.
11:48 pmoreau: Well, at least the NVIDIA card did
11:48 Celelibi: Basically, I boot, I run lspci, lspci locks up.
11:49 pmoreau: Try booting with `nouveau.runpm=0`
11:49 tacchinotacchi: I confirm that tracing doesn't work correctly on my ck kernel
11:49 Celelibi: Ok, let's try.
11:49 pmoreau: Battery life will be worse, but that should hopefully avoid those hangs
11:50 tacchinotacchi: even making the buffer wider, it stalls my cpu and does nothing
11:50 Celelibi: pmoreau: where do I set this?
11:50 tacchinotacchi: as in, it takes forever to boot the card with bumblebee
11:51 pmoreau: Similarly to other boot arguments: in grub when selecting the entry, or in /etc/modprobe.d/some_file.conf but then it should be prefixed by option (or options, I am not sure)
11:51 pmoreau: tacchinotacchi: Forever being how long?
11:51 tacchinotacchi: few minutes
11:51 pmoreau: Seems reasonnable
11:52 tacchinotacchi: the other kernel does it in 5 seconds
11:52 pmoreau: Eh
11:52 tacchinotacchi: Maybe it will eventually, but I'm not willing to wait more with my cpu stalled right now
11:52 tacchinotacchi: this notebook's cooling isn't good enough
11:52 pmoreau: What is this ck version of the kernel doing?
11:52 tacchinotacchi: what do you mean?
11:53 pmoreau: What is the difference between a ck version of the kernel, and a regular one?
11:53 karolherbst: pmoreau: ck kernel, has some patches
11:53 pmoreau: Ok
11:54 karolherbst: stuff like BFQ and BFS
11:54 tacchinotacchi: https://wiki.archlinux.org/index.php/linux-ck
11:54 tacchinotacchi: it reduced audio lag when I play stepmania ( and osu, when wine works ) :)
11:55 tacchinotacchi: I'll reboot into ARCH kernel before my cpu melts
11:56 Celelibi: pmoreau: should be "options nouveau runpm=0" right?
11:57 pmoreau: Yes
11:58 Celelibi: Ok, I'll eat and try this.
11:58 Celelibi: I also blacklisted nvidia. Should be enough?
11:58 tacchinotacchi: I confirm
11:59 pmoreau: Nouveau is usually loaded before NVIDIA does, and NVIDIA aborts if it finds Nouveau IIRC, so it should be fine even without the blacklist
11:59 Celelibi: perfect
11:59 Celelibi: (wrong window)
11:59 tacchinotacchi: "optirun bash", which should have the only effect of booting the gpu, takes about 5-10 seconds on ARCH
12:00 tacchinotacchi: and far more on ck, if at all
12:06 tacchinotacchi: pmoreau: is 5 to 10 seconds unusual?
12:07 pmoreau: I have never used optirun, so I don’t know. It seems a tiny bit slow, but nothing excessive
12:10 tacchinotacchi: optirun usually takes 3 seconds even without mmiotrace
12:22 karolherbst: well, mmiotrace slows things down
12:22 karolherbst: ohh you mean without tracing
12:23 karolherbst: well it depends on what you do
12:42 pankike: hi
12:42 tacchinotacchi: any idea what is going on here? ( diff between -100mhz and +200 mhz )
12:42 tacchinotacchi: http://pastebin.com/u6sKj16P
12:42 tacchinotacchi: between -100 and -200 *
12:42 pankike: there was a livecd with newest unstable nouveau that support latest nvidia cards, but i forgot what was the name of it, can someone remind me it?
12:43 tacchinotacchi: after the pastebin, it sends the same data, but then it looks like it's writing it at a different offset
12:55 pmoreau: pankike: There is https://nouveau.pmoreau.org/ but it's been broken for some time as you can see. I have some fixes locally which I haven’t pushed yet to the server. Might do that in about ~5-6 hours, so the image won’t be available before tomorrow morning if all goes well.
12:55 pankike: right
12:55 pankike: ok this is what i've been looking for
12:56 pankike: many thanks my mate :)
12:57 karolherbst: tacchinotacchi_: you can ignore those offsets
12:58 pankike: pmoreau are there any instructions how to install latest nouveau from within debian stable from terminal (i meant tty)? because last time i had huge problems to get git versions to work, but your livecd did the job great and i had no artifacts
12:59 pmoreau: Hum…
13:01 pmoreau: Not that I know of.
13:03 pankike: ok, thanks, i will use your live cd tomorrow
13:10 tacchinotacchi_: Karohelbst: have time to explain why? ;)
13:26 karolherbst: tacchinotacchi_: because they are just to tell the PMU from where to read the data
13:26 karolherbst: basically
13:26 karolherbst: it's part of the transport protocol
13:53 Celelibi: pmoreau: well, I couldn't get nouveau to load at startup, even after I commented out all the "blacklist nouveau".
13:54 Celelibi: But I stopped X, loaded it, restarted X. And it seems to work.
13:54 Celelibi: with runpm=0
14:00 Celelibi: So I guess you were right, it was related to the power management.
14:02 Celelibi: Tell me if you want me to test anything else.
14:11 pmoreau: Celelibi: You should open a bug report on bugs.freedesktop.org, so that there is a trace of the bug at least, and upload there the full dmesg.
14:13 pmoreau: I don’t know what is going on, so I am not sure what additional information would be needed. Maybe know to which line in the code gf119_disp_root_init+0x207/0x320 corresponds to?
14:27 karolherbst: pmoreau: loop
14:28 karolherbst: still odd
14:28 karolherbst: there is just the "for (i = 0; i < disp->base.head.nr; i++)" loop
14:28 karolherbst: nvkm_mask(device, 0x616308 + (i * 0x800), 0x00000111, 0x00000010);
14:29 karolherbst: ohh wait
14:29 karolherbst: it is the nvkm_msec code
14:29 karolherbst: odd
14:29 karolherbst: it should abort after two seconds
14:29 karolherbst: gf119_disp_root_init+0x1e2 calls nv04_timer_read
14:29 karolherbst: so gf119_disp_root_init+0x20 is nearby
14:30 karolherbst: which is the nvkm_rd32 in that nvkm_msec loop
14:30 karolherbst: except, the timer is broken as well
14:30 karolherbst: sounds like GPU is messed up for real
14:31 karolherbst: I already said, that we shouldn't trust the GPU timer alone, because this causes silly issues like this
14:42 RSpliet: hakzsam: saw your push, nice work!
14:43 RSpliet: karolherbst: keen on re-using his work for Kepler? :-P
14:43 hakzsam: RSpliet: thanks
14:45 RSpliet: 'd love to dive into this code soon :-)
14:46 mupuf: RSpliet: kepler is already quite good, IIRC
14:47 RSpliet: mupuf: isn't it much simpler?
14:47 mupuf: http://www.phoronix.com/scan.php?page=news_item&px=NVC0-Maxwell-Pascal-GL43-Lands <-- this did not take long
14:47 RSpliet: I'd have to look at what hakzsam's code does and doesn't do, but determining the sched codes is only the first of tedious tasks
14:47 mupuf: maybe the technique hakzsam used to time the latency of instructions could be used
14:48 RSpliet: actually reordering instructions to minimise latencies (maximise dual issue) is the next step in perf improvement :-)
14:48 hakzsam: the technique is to look at blob shaders :)
14:48 hakzsam: RSpliet: definitely yeah
14:48 hakzsam: and maxas has been really useful
14:50 karolherbst: RSpliet: huh? what do you mean
14:50 karolherbst: ohh you mean the parser
14:50 karolherbst: mhhh
14:50 karolherbst: might come in handy
14:50 karolherbst: we have a few silly cards
14:50 karolherbst: ben have them
14:50 karolherbst: *has
14:50 RSpliet: no I wasn't talking about a parser, but yes, that could be cool too :=D
14:50 karolherbst: :D
14:50 RSpliet: * :-D
14:51 RSpliet: I have to admit that if this takes him 30 minutes to publish... that's some serious productivity
14:52 karolherbst: RSpliet: might be pre written already though
14:52 mupuf: very likely, yeah
14:52 karolherbst: if you want to be fast, you have to know the stuff before it actually happens anyway
14:53 Celelibi: pmoreau: it's hard to get the dmesg output since I can barely run anything once the bug has been triggered. :s
14:53 RSpliet: karolherbst: that's a quote for the records
14:54 karolherbst: RSpliet: well, you can still change things later on :p
14:54 karolherbst: we have to fix nvkm_msec ... otherwise we will always get annoying reports like those
14:55 karolherbst: Celelibi: basically your GPU messes up in some way, where your dmesg doesn't help with to begin with
14:55 karolherbst: it just reports "GPU messed up, no clue why"
14:56 karolherbst: it is related to suspending the GPU, that's for sure
14:57 karolherbst: maybe the ACPI method does something nouveau didn't expect at this point or something else is broken in a crazy way
14:57 Celelibi: Ok, got the dmesg. Time to reboot to something sane.
15:03 karolherbst: mupuf: wanna come to sha2017?
15:04 mupuf: hmm, sounds fun
15:05 RSpliet: it is fun!
15:05 mupuf: oh, you need to pay to go there :s
15:05 mupuf: that sucks
15:05 RSpliet: yes, it's a week-long camping event
15:05 mupuf: well, it may be worth it
15:05 RSpliet: I went four years ago (OHM2013)
15:06 RSpliet: it can be perceived a smaller version of the CCC camp they organise every four years
15:07 karolherbst: mupuf: it has internet
15:07 karolherbst: and power :p
15:08 mupuf: mesa 17 is going to be one hell of an update
15:08 RSpliet: https://orga.sha2017.org/images/b/bb/User_Bitlair.nl-kartoffel_Picture.jpg - and people who hack segways out of club mate crates
15:08 mupuf: lol
15:08 karolherbst: RSpliet: that's for starters
15:09 mupuf:sees no hack here :D
15:09 karolherbst: yeah, normal stuff, nothing special :p
15:09 RSpliet: anyway, it officially has 3000 visitors, serious internet, power... probably a GSM or DECT network as well
15:09 RSpliet:knows part of the organisation team
15:09 karolherbst: RSpliet: how much internet? :D
15:09 mupuf: I mean, the only thing that the guy did was putting a crate on top of his ... little segway, whatever name it has
15:10 mupuf: not saying anything, I'm sure it is fun
15:10 karolherbst: I only consider a 180GBit link serious :p
15:10 mupuf: but it is not a hack :D
15:10 mupuf: karolherbst: ahahah
15:10 karolherbst: I am not joking
15:10 mupuf: RSpliet: that sounds pretty good
15:10 karolherbst: the 33c3 actually had a 180Gbit connection
15:10 karolherbst: :D
15:10 mupuf: all that matters is speed/attendees ;)
15:11 karolherbst: s/attendees//
15:12 karolherbst: allthough actually just 35GBit were used and 80GBbit planned, but then there was a nice ISP providing additional 100Gbit.....
15:12 mupuf: lol
15:12 karolherbst: and then two of those 100Gbit backbone routers
15:12 karolherbst: it was quite fun
15:12 RSpliet: karolherbst: I'll have to disappoint you though... it's most likely going to be just 100Gbps through NIKHEF
15:13 karolherbst: :(
15:13 karolherbst: weak
15:13 karolherbst: RSpliet: isn't the NOC and VOC from the c3 doing that stuff for sha2017 anyway?
15:13 Celelibi: Should I report the bug in the xorg product even though it's the kernel module that is buggy?
15:14 karolherbst: Celelibi: yes
15:14 RSpliet: karolherbst: no, it's the NOC team that's been doing OHM2013
15:14 karolherbst: okay, and who does it for sha2017?
15:16 karolherbst: RSpliet: I didn't ask you by the way, cause I automatically assumed you will come anyway :p
15:16 RSpliet: karolherbst: not sure yet
15:16 karolherbst: :O
15:19 karolherbst: anyhow, it would be nice to get something nouveau related working on sha2017 or 34c3 (whenever this will be)
15:20 RSpliet: or just get together for a day of outdoor hacking...
15:23 Celelibi: My kernel is tainted, can I know why?
15:23 karolherbst: well I will go to sha2017 in any case
15:23 karolherbst: Celelibi: nvidia
15:28 karolherbst: RSpliet: but true, we could actually meet up at some other point as well to do nouveau stuff or something else or whatever :p
15:29 karolherbst: I don't know, somehow thinking about going to fosdem sounds like a bad idea every day I think about it, not even the talks are interesting :/
15:29 RSpliet: Bigger events like this are a good incentive though... not nice for the Scandi's to fly over just for a day of hacking
15:30 karolherbst: yeah
15:30 Celelibi: Should I include an lspci in my bug report or something?
15:30 karolherbst: 33c3 would have been perfect, because it was just 100€
15:31 karolherbst: but I got my ticket like the day before the event, cause it was sold out :D
15:31 RSpliet: yeah... I can imagine it sells out quickly, I mean there were only 13.000 tickets
15:31 karolherbst: it was basically like this:
15:31 karolherbst: they opened the web shop and if you got there 5 seconds after it opened, it was too late
15:31 karolherbst: they sold around 2k tickets on three days
15:32 karolherbst: and before that, there were already those 6k tickets given away and sold to the hacking spaces and erfas
15:32 Celelibi: Or maybe it's the first lockup that tainted the kernel?
15:33 karolherbst: Celelibi: or this
15:33 tacchinotacchi_: RSpliet: do you have a branch with the latest Fermi code, or is it in the main one?
15:33 karolherbst: it should tell you why though
15:33 Celelibi: Here is the report: https://bugs.freedesktop.org/show_bug.cgi?id=99385
15:34 karolherbst: Celelibi: as I thought, the dmesg doesn't really help with the issue :(
15:34 RSpliet: Celelibi: L|_ : if a soft lockup has previously occurred on the system.
15:34 Celelibi: Well, just tell me.
15:34 RSpliet: so it's tainted because of the lock-up
15:34 Celelibi: ok.
15:59 Celelibi: How do I know which module is in use in xorg?
16:09 RSpliet: Xorg.0.log (or the SystemD equivalent)
16:16 Celelibi: Hm. I have actually two VGA controllers.
16:16 Celelibi: Not sure how this is supposed to work.
17:40 imirkin_: RSpliet: kepler's already set wrt sched codes... has been for quite a while
17:41 imirkin_: RSpliet: both could use an actual scheduler, but that's different.
18:15 imirkin_: karolherbst: have you investigated plumbing logic to reclock GM20x on mobile parts, where we don't need to do fan control?
18:15 imirkin_: i.e. providing the internal interfaces to load up our pmu over the nvidia-signed one after the chip is initially turned on?
18:16 karolherbst: it's already there
18:16 karolherbst: secboot just messes things up
18:16 imirkin_: that's my point -
18:16 karolherbst: if you disable the secboot subdev, nouveaus pmu image gets loaded if you also set up the pmu subdev
18:16 imirkin_: providing the internal interfaces to make secboot work and THEN load the nouveau pmu image
18:17 karolherbst: ohh I see
18:17 karolherbst: mhh
18:17 karolherbst: I think gnurou reworks helped a lot here
18:17 imirkin_: and also flipping it on by default if there are no fans detected or something
18:17 karolherbst: didn't had much time to dig into it yet
18:17 karolherbst: imirkin_: we can't detect if there is no fan
18:17 imirkin_: why not?
18:17 karolherbst: because nvidia thinks on my chip is a fan :p
18:18 imirkin_: your chip isn't affected by this
18:18 karolherbst: I think mupuf once told me there is no reliable way to figure it out
18:18 karolherbst: well
18:18 imirkin_: we should look at the ones that are, and see if e.g. there's a GPIO for it or whatever
18:18 karolherbst: we could figure that there is no fan _for_real_, but this won't cover all mobile chips
18:18 imirkin_: yeah
18:18 imirkin_: we could also add an override to let users flip it on
18:18 karolherbst: this would be also fine for desktop chips with no fan
18:19 imirkin_: like nouveau.IPromiseThereIsNoFan=1 :)
18:19 karolherbst: mhh
18:19 karolherbst: good idea
18:19 karolherbst: I can dig into it
18:19 imirkin_: figured that it's in your expertise area, so might be good to take a look
18:20 karolherbst: yeah
20:18 nyef: Hrm. Initial poking about suggests that EGL_EXT_multiview_window doesn't apply to what I'm doing: It's at the EGL level, which is described as an OpenGL-to-windowing-system layer, but that role for X11 is taken up by GLX.
20:19 nyef: Which would also mean that the OpenGL APIs for stereo remain the same: GL_STEREO and friends.
20:24 nyef: ... Or I could be misunderstanding how this all works even in X11 these days.
20:43 karolherbst: maybe I can reproduce this epiphany issue. would be nice
20:44 imirkin_: nyef: you can use EGL with X11
20:54 nyef: Oh, lovely.
20:55 nyef: I'm also getting distinctly mixed signals on stereo support from mesa.
22:40 imirkin_: mwk: do you remember what FMUL.FMZ does precisely? is it 0 * NaN or 0 * Inf?
22:52 imirkin_: nyef: mesa has none.
22:52 imirkin_: [i thought i covered that before]
22:53 imirkin_: nyef: step 1 is forget about mesa, and figure out how this is going to work over the DRI2/DRI3 protocols
23:02 nyef: So... use a hypothetical program to open an X server connection and set up a 3D image, and figure out how to make it actually happen instead of being hypothetical?
23:02 imirkin_: :)
23:02 imirkin_: at least that'd be my approach
23:03 imirkin_: by the time you get to mesa, you should have your other shit figured out
23:03 imirkin_: otherwise you're going to be hacking for a LONG time with zero tangible results
23:03 imirkin_: until it magically all works, of course
23:04 mwk: imirkin_: I think both
23:05 imirkin_: mwk: ok, so it's the same as flipping it in ISA_FLAGS?
23:05 mwk: I don't know about the FMZ modifier on Fermi, but the equivalent Tesla switch does 0 * anything == 0
23:05 nyef: Looks like the DRI2 protocol has stereo buffer support already specified, though I have no idea about implementation yet.
23:05 mwk: imirkin_: no idea, I only checked on Tesla
23:05 imirkin_: mwk: right ok
23:06 imirkin_: nyef: cool. less protocol changes = less crying in your pillow
23:06 mwk: IIRC it also converts -0 to +0, or something
23:10 imirkin_: mwk: is it xtra >> 1 & 1 in your hwtests?
23:11 mwk: I think so, yes
23:11 imirkin_: uint32_t fp32_mul(uint32_t a, uint32_t b, enum fp_rm rm, bool zero_wins) {
23:11 imirkin_: presumably zero_wins :)
23:11 mwk: yep
23:14 mwk: wtf, NV40
23:14 mwk: where do you store your half-processed primitives...
23:15 mwk: there's only one place that seems to fit, and the nvidia ctxprog goes out of its way to avoid saving/restoring it....
23:26 pmoreau: Hopefully images should building again. We will see tomorrow whether it worked or not (but it did work locally at least).