00:00 imirkin: mupuf: at the very least, one has connectors the other does not, i think
00:08 mupuf: yeah, sounds right
01:49 imirkin: gnurou: how's that gp104 firmware coming along?
01:50 gnurou: imirkin: let's not talk about things that may hurt
01:51 imirkin: i see. so... never?
01:51 gnurou: definitely not never
01:51 airlied: just not an acceptable ever :-P
01:51 imirkin: but not until the quartz line is out? :)
01:52 gnurou: I expect things to go better than they did for Maxwell
01:52 imirkin: [just making guesses... no physicist starting with the letter q comes to mind]
01:52 gnurou: but I have very little influence on the process and this is very frustrating
01:52 imirkin: i can imagine.
06:03 kloofy: loon is back, actually when there are scratch regs 8 of them, and if each scratch reg would be per wavefront/warp then this would make things easy, and i'd take back my words about poor isa
07:13 inglor: mupuf: yay! \o/ it's working
07:13 mupuf: inglor: seems like it, indeed! Thanks a lot!
07:14 inglor: sure! so how does one gets involved to the dev? I'd be interested to get my hands dirty
07:17 mupuf: inglor: what are you interested in?
07:17 mupuf: You need to want to scratch a bad itch
07:18 mupuf: you talked about PM before, it may be a bit tough, but there may be still be easy-ish tasks
07:34 karolherbst_work: mupuf: nice
07:35 mupuf: :)
07:36 karolherbst_work: by accident, I found a MB for 100€ with 3x pcie + 2x pci
07:37 karolherbst_work: interested? :D
07:37 mupuf: yep
07:37 karolherbst_work: http://geizhals.eu/asus-z87-a-c2-90mb0dz0-m0eay5-a981524.html?hloc=at&hloc=de&hloc=pl&hloc=uk&hloc=eu
07:37 karolherbst_work: I have to buy a new machine for myself and was looking around
07:37 mupuf: so, I have all chipsets of tesla, I am missing the c3 and d7 for fermi
07:38 karolherbst_work: ohh actually there is a 4th pcie as well, but only x1
07:38 karolherbst_work: and sadly closed :/
07:38 karolherbst_work: (2 actually)
07:38 mupuf: GK110/B, GK208B and GK210 for kepler
07:38 karolherbst_work: do you think the gk110/b is that different?
07:39 mupuf: GM108/200/204/20B for maxwell
07:39 mupuf: the 20B I should be able to get my hands on it
07:40 karolherbst_work: anyway, a mb with 3x pcie would be nice, so that we can always have 3 gpus in it and we don't have to switch that often. Sadly this MB has a really stupid layout for the slots :/
07:41 mupuf: well, the last slot is really low, that's a bit bad
07:41 karolherbst_work: yeah
07:41 karolherbst_work: but fermis/teslas are usually single slot, right?
07:41 karolherbst_work: with kepler they all went insane :p
07:41 mupuf: tesla, yes
07:42 mupuf: fermi ... I have one that is single slot
07:42 Tom^: karolherbst_work: http://amfeltec.com/products/flexible-x4-pci-express-4-way-splitter/
07:42 Tom^: ;)
07:42 karolherbst_work: it is just silly, that the PCI ones are blocked with dual slot cards
07:42 mupuf: karolherbst_work: who cares about PCI?
07:42 karolherbst_work: Tom^: they are also closed :/
07:42 karolherbst_work: mupuf: you don't have any PCI gpus?
07:43 mupuf: just one, and it busts nouveau
07:43 karolherbst_work: I have a fx 5200 somewhere, no clue where though :D
07:43 mupuf: well, try to find it for XDC then :p
07:43 karolherbst_work: good idea actually
07:43 mupuf: but yeah, I should build a machine just for CI
07:43 karolherbst_work: ohhh
07:44 karolherbst_work: it is a AGP one
07:44 karolherbst_work: right....
07:44 Tom^: isnt pcie hotpluggable?
07:45 karolherbst_work: 4 pcie slots for 180€, mhhh
07:45 mupuf: https://www.asus.com/us/Motherboards/P9X79E_WS/ :D
07:45 Tom^: if i were you i would get one of those pcie extension cable so you can hotplug it outside the case anyhow
07:45 karolherbst_work: mupuf: :D
07:45 karolherbst_work: mupuf: when the only thing that matters are the GPUs :p
07:46 mupuf: that sounds about right :D
07:46 karolherbst_work: 440€ :p
07:46 karolherbst_work: mupuf: http://geizhals.eu/asrock-z87-extreme9-ac-90-mxgqa0-a0uayz-a953885.html
07:47 karolherbst_work: 2 dual + 2 single slot
07:47 karolherbst_work: actually 3 single slot
07:47 karolherbst_work: ohh, sounds ncie actually
07:47 mupuf: will be problematic because all the GPUs we care about are dual slot
07:47 karolherbst_work: 5 pcie slots for 180€, that sounds fair
07:48 karolherbst_work: yeah
07:48 karolherbst_work: well
07:48 karolherbst_work: or 3 dual slot + 1 single slot ;)
07:48 mupuf: but I guess I can put some tesla GPUs
07:48 mupuf: yeah, this sounds about right
07:48 karolherbst_work: but the top one is x8 only, like we care :p
07:48 mupuf: one fermi, one kepler, one maxwell
07:48 mupuf: I have an old nv86 laptop which I can use for CI
07:48 karolherbst_work: well, so the last MB is either 2 dual + 3 single, or 3 dual + 1 single
07:49 karolherbst_work: ASRock Z87 Extreme9/ac
07:50 mupuf: 3 dual + 1 single --> That can cover the one GPU of each family, minus pascal
07:50 karolherbst_work: mupuf: maybe we could also setup some virtualisation and run several vms, where each one gets one GPU :3
07:51 karolherbst_work: mupuf: or one of them will be single slot (like low end gpus)
07:51 mupuf: yeah, that is one way of doing it, but then, we could not trust performance data
07:51 Tom^: karolherbst_work: so what kind of PSU do you plan on? a nuclear reactor?
07:51 mupuf: Tom^: yep, sounds about right
07:52 karolherbst_work: huh, Z87 doesn't supports VT-d :/
07:52 mupuf: but I will not put titans there
07:52 karolherbst_work: what trash
07:52 mupuf: just x60 or x70 series
07:52 karolherbst_work: but I guess for 180€ you don't get everything you want :D
07:52 mupuf: they need one power connector usually
07:52 mupuf: so it is manageable
07:52 mupuf: karolherbst_work: DDR3 sucks though, but it must be cheap now
07:53 karolherbst_work: yeah
07:53 mupuf: so... probably a good idea
07:53 karolherbst_work: it sounds fair
07:53 karolherbst_work: because currently all we have are 2 slots :p
07:53 Tom^: i wonder if you simply cant find some refurbished motherboards tho
07:53 karolherbst_work: and with 4 slots, we don't have to bother you everytime :D
07:53 karolherbst_work: Tom^: it shouldn't break after a year or so :p
07:54 Tom^: http://www.newegg.com/Product/Product.aspx?Item=N82E16813128852&cm_re=refurbished_motherboard-_-13-128-852-_-Product
07:54 Tom^: cheap :p
07:55 karolherbst_work: trash :p
07:55 karolherbst_work: 3 gpus top, so
07:55 karolherbst_work: the board with 4/5 is actually good enough
07:56 Tom^: speaking of which, gonna look for some refurbished micro atx to build some pfsense box.
07:56 karolherbst_work: Tom^: so that one would be 150€ (taxes + shipping included)
07:56 karolherbst_work: so we rather choose the 180€ one :p
07:56 Tom^: mmh
07:56 Tom^: didnt think of taxes
07:57 karolherbst_work: yeah, we talk about prices with taxes included here, like every sane human would do :p
07:58 mupuf: well, I really think of this one as CI that will allow sending jobs to
07:58 mupuf: but that's it. I do not know if I will give access to people for development
07:58 mupuf: the goal here is to track performance and unit tests
07:58 mupuf: and do image validation
07:59 karolherbst_work: mupuf: ahh, okay
07:59 karolherbst_work: sounds good though
07:59 mupuf: anyway, I will have a look at the intel employee program to save on CPUs
07:59 mupuf:would rather have more ram or a better PSU than spend money on a CPU
08:00 karolherbst_work: right
08:00 mupuf: but I have to have an OK CPU if I do not want to be CPU-limited
08:00 karolherbst_work: yes
08:00 karolherbst_work: some games are CPU bottleneck in really ugly ways though
08:00 mupuf: another possibility would be for me to just buy a new desktop machine and let my 4790k go to this machine
08:00 mupuf: or I could use my current desktop machine as reator2
08:00 gruetzkopf: huh, there are *still* platforms that don't support VT-d?
08:00 karolherbst_work: but that would be like more expensive
08:01 mupuf: karolherbst_work: yes, this is what I am afraid of
08:01 chithead: vt-d is only available on more expensive intel cpus
08:01 gruetzkopf: i'm spoiled by 8-year-old laptops then
08:01 mupuf: well, I guess I will have a look
08:02 mupuf: maybe I can get a cheap skylake for my main PC. I really don't like the performance of my hsw GPU and I don't really want to put an nvidia gpu on my desktop
08:02 mupuf: tough choices
08:03 mupuf: anyway, got to go!
08:07 karolherbst_work: chithead: we talk about MBs here though :p
08:07 karolherbst_work: or I meant a mb
08:26 Tom^: did i just get gl 4.4 on swrast? http://ix.io/17wc
09:01 hakzsam: hehe, 3 cards in reator, fun!
09:05 mwk: hakzsam: 2 cards, 3 GPUs :)
09:06 hakzsam: sure :)
09:08 Horrorcat: karolherbst_work: I tried your kepler-reclocking-branch a few weeks ago with linux-4.5.0, do you recall? Is it possible that, even though I do not use the nvidia gpu actively, the modified nouveau.ko reduces the power consumption of the idle system?
09:08 Horrorcat: I am trying to track down what is causing the increased power consumption with 4.6.0 and thought of re-building the nouveau.ko I built back then, but it fails to compile, so the next follow-up question would be "is there a recent version of your stable_reclocking_kepler_v5 which builds against 4.6.0"
09:11 Tom^: Horrorcat: the recent one already does.
09:12 Tom^: Horrorcat: there is even a seperate branch for 4.7.x
09:13 Horrorcat: ah, the pull failed. after your comment I realised that I should probably have tried a "force pull", which seems to work.
09:13 Horrorcat: thanks!
09:20 karolherbst_work: Horrorcat: the power reading isn't exactly perfect in either nouveau version
09:21 karolherbst_work: you also need this patch on top of a recent branch: https://github.com/karolherbst/nouveau/commit/0469626778c7b0f74c195476a3639a0dd0ff1890
09:21 karolherbst_work: mupuf: by the way, did you look over this patch at some point?
09:39 mupuf: karolherbst_work: I never really checked it
09:39 mupuf: wouldn't be a bad idea to!
09:52 karolherbst_work: mupuf: would be really helpful yes, because that's the first version where I feel good enough to say, it usually prints the right thing ;)
09:52 karolherbst_work: but this was messy to figure out :/
09:52 karolherbst_work: and too obvious :D
10:12 mupuf: karolherbst_work: ah ah
10:12 mupuf: yeah, it is messy when you can't check the power output reported by nvidia
10:12 mupuf: but one GPU was exposing this, right?
10:12 mupuf: forgot which one, tesla?
10:21 karolherbst_work: mupuf: the titan
10:22 mupuf: err, I meant titan of course :FD
10:22 karolherbst_work: it helped a lot
10:22 karolherbst_work: it also showed some crazy nvidia behaviour
10:22 karolherbst_work: maybe more like hw behaviour
10:22 karolherbst_work: the sensor boots with everything enabled and after nvidia configures it, it isn't reset
10:23 karolherbst_work: so if you disable a lane with something attached, the old value gets stuck
11:31 night199uk: mupuf: thanks for the pointers yesterday - they really helped. i figured out most of what I wanted to with the plls :-)
11:31 mupuf: night199uk: wonderful!
11:31 night199uk: mupuf: one more quick q?
11:31 night199uk: mupuf: so once i realised that the vplls could have different source clocks most of the rest of the code i was looking at made sense
11:32 night199uk: mupuf: i just wondered if you had any more on the sources for the vplls? i notice the pll layouts you sent me were for 0x137000 - these aren’t vplls, right?
11:32 night199uk: those must be RAM plls or other i guess?
11:33 night199uk: i’m trying to understand a bit more about the clock sources themselves now
11:33 night199uk: so in nouveau i see ‘sppll0’, ‘sppll1’ and also mentions of ‘rpll'
11:35 night199uk: so it seems theres a 27Mhz base clock and a 100Mhz base clock, which the VPLLs can source directly from. or alternately they can be sourced from a parent PLL. I’m trying to figure out of those parents are RPLL, SPPLL0/1, or something else
11:37 night199uk: (the plls i’m trying to figure out are those at 0xe800 and 0xe8200)
11:37 night199uk: er, 0xe820
11:38 night199uk: and they seem to be the alternate bases for the vplls at 0x614140, 0x614940, etc
11:39 night199uk: so if i’m right it’s baseClock (27mhz)->PLL (0xe800)->VCO->PLL(0x614140)->VCO->Output (SOR, Connector or Macro)
11:42 mupuf: night199uk: so, you are basically trying to understand the clock tree
11:42 night199uk: yes :-)
11:43 night199uk: that would be a better summary than my waffling
11:43 mupuf: a PLL is a PLL, whatever it is used for
11:43 mupuf: so, VPLL, RPLL, SPPLL or whatever is just a fucking clock, nothing more
11:43 mupuf: indeed, there are two clock sources
11:44 mupuf: a 27 MHz crystal and the PCIE's reference clock (100 MHz)
11:44 night199uk: aha
11:44 mupuf: after this, the root PLLs increase the frequency to ~405 MHz IIRC
11:44 night199uk: RPLL = Root PLL?
11:45 mupuf: and this is either divided or multiplied later on, when getting closer to the engines
11:45 mupuf: yes
11:45 mupuf: but, as I said, it is not really important
11:45 night199uk: sure
11:45 mupuf: the reason why there may be multiple levels of PLLs is because it you can't really multiply a clock by a factor of a hundred and get a stable output clock
11:46 mupuf: it is too hard
11:46 mupuf: so they have up to 3 levels IIRC (for the RAM)
11:46 mupuf: crystal -> RPLL -> ram pll stage 1 and then stage 2
11:46 mupuf: engines typically have a mux being able to select if the clock you want to use
11:47 mupuf: it can be directly the crystal clock, the PCIe clock, a divider or a PLL
11:47 mupuf: the same is possible for the input clock of the divider or the PLL (they have muxes to select the input)
11:48 mupuf: if you want to draw the entire clock tree, good luck
11:48 night199uk: heh
11:48 night199uk: i was thinking about it
11:48 night199uk: not a good plan?
11:49 mupuf: isn't it a waste of time?
11:49 night199uk: maybe
11:49 night199uk: just useful reference for others :-)
11:49 night199uk: spent too much time scratching my head and asking you guys too many stupid questions
11:49 mupuf: http://phd.mupuf.org/files/xdc2013-nvidia_pm.pdf
11:49 mupuf: page 3
11:50 night199uk: aha
11:50 mupuf: II.D is basically what you want to read
11:51 mupuf: and if you care about PM, you can check out my phd thesis which has way more information: http://phd.mupuf.org/files/these_martin.pdf
11:51 mupuf: inglor, night199uk: chapter 5 ^
11:53 night199uk: superb
11:53 night199uk: so just in terminology - RPLL = Root PLL, what is SPPLL?
11:53 mupuf: heck if I know
11:54 night199uk: VPLL = Video PLL (right before the connector for Pixel Clock)
11:54 mupuf: or care, really
11:54 night199uk: haha
11:54 night199uk: okay :-)
11:54 mupuf: Shader Processor PLL?
11:54 mupuf: name PLLs by their addresses :p
11:54 night199uk: so you’d call 0xe800...?
11:57 night199uk: that first nvidia-pm doc answers many questions i had, thanks… shame i didn’t have this a few days ago :-)
11:59 mupuf: night199uk: sorry I did not let you know I had all this stuff
11:59 mupuf:has been involved with nouveau-pm for years now
11:59 mupuf: > 6 years actually
11:59 mupuf: time flies
11:59 night199uk: no worries, hardly your fault, i only asked yest :-)
12:00 night199uk: i’ve spent the last 3 years building this uefi driver
12:00 night199uk: nearly 4 now
12:00 night199uk: was only supposed to be a 6 month project :-)
12:01 mupuf: lol
12:10 SaveTheRobots: hi karolherbst_work, is it still recommended to you use your github repo (branch: stable_reclocking_kepler_v5_4.7) for best performance with my 780 Ti, or can i just use the newly released 4.7 kernel?
12:18 karolherbst_work: SaveTheRobots: well, I will update to 4.7 in the near future
12:18 karolherbst_work: but it is still the same branch until I post on the ML
12:19 karolherbst_work: night199uk: :D
12:19 karolherbst_work: sometimes things get out of control
12:20 karolherbst_work: night199uk: why not porting nouveau to uefi?
12:21 SaveTheRobots: karolherbst_work: ah thanks, so it's recommended to use the stable_reclocking branch on 4.6 until you rebase to 4.7 ?
12:21 karolherbst_work: night199uk: most of the things should be abstracted away anyway and only the system layer would have been to be implemented (and a few uses of Linux APIs, but we've done that for userspace already)
12:22 karolherbst_work: SaveTheRobots: it will be the same branch
12:22 karolherbst_work: SaveTheRobots: ohh, you mean the stable_reclocking_kepler_v5_4.7 branch
12:22 karolherbst_work: mhhh
12:22 SaveTheRobots: karolherbst_work: yeah, sorry, i've been out of the loop for a while, so i'm jsut wondering which branch is best to use :p
12:22 SaveTheRobots: sorry, poorly worded question
12:23 karolherbst_work: well, there are no functional changes yet anyway on my more recent branch
12:23 karolherbst_work: just some changed due to reviewing
12:23 karolherbst_work: (and more commits from upstream nouveau)
12:24 SaveTheRobots: ah ok
12:25 SaveTheRobots: i've just updated to 4.7 and the binary nvidia driver fails to compile, a simple patch fixes it but i figured, why not move to nouveau for a while, since all i play atm is pillars of eternity (not exactly gfx hungry)
12:25 karolherbst_work: night199uk: I know that suggestion might come a little late, but this would be the thing I would do and it will also include newest stuff
12:25 SaveTheRobots: i'll give vanilla 4.7 nouveau with latest mesa a try, i guess i don't need mesa-git
12:26 karolherbst_work: SaveTheRobots: with vanilla, reclocking might crash your gpu randomly :p
12:26 karolherbst_work: or won't reclock at all or something like that
12:26 SaveTheRobots: ahh ok
12:27 SaveTheRobots: stable_reclocking_kepler_v5_4.7 it is then
12:28 SaveTheRobots: i know this isn't the best place to ask this, but maybe you know... is it worth me using mesa-git, will i see any performance/stability improvements over 12.0.1 ?
12:29 night199uk: karolherbst_work: yeah, too late :-)
12:29 night199uk: one of those hindsight is 20:20 vision things
12:30 night199uk: when i set out on this i expected there’d be stuff in the uefi drivers that wasn’t in nouveau
12:30 night199uk: but it seems like you have nearly everything covered
12:30 night199uk: still, i think porting nouveau to uefi model would be pretty hard
12:30 night199uk: and there are some real size limits
12:31 karolherbst_work: SaveTheRobots: chances are, that with mesa-git things are better
12:31 night199uk: now i’m so far down this track i would never start again from the beginning
12:31 karolherbst_work: night199uk: well, you don't have to include everything.
12:32 karolherbst_work: night199uk: and what size limits?
12:32 karolherbst_work: I thought uefi should be free of that crap :D
12:32 night199uk: well, the nvidia roms are very limited
12:32 night199uk: 128Kbit or 256Kbit I think
12:32 night199uk: more room in the BIOS itself which is how i’m loading it now
12:32 karolherbst_work: and?
12:32 karolherbst_work: the uefi driver could be on a fs as well with uefi
12:33 night199uk: well, yeah
12:33 SaveTheRobots: karolherbst_work: awesome, thanks dude
12:33 night199uk: but in that case you couldn’t have it overload the card driver
12:33 night199uk: (the PCI ROM would take preference)
12:33 karolherbst_work: night199uk: but I thought uefi roms are pretty big by now
12:33 night199uk: yeah, lots of people are putting big ROMs
12:33 night199uk: but not nvidia :-)
12:33 karolherbst_work: :D
12:35 karolherbst_work: night199uk: well, my idea would be 1. let nouveau compile against uefi 2. load the nouveau uefi driver from the uefi shell (or somewhere, or however that works) 3. add compile conditions inside nouveau to reduce code size
12:37 karolherbst_work: in theory, the uefi driver could also be used from other OS, but doing advanced stuff might be too tricky
12:37 mlankhorst: karolherbst_work: well, fun with hw handover!
12:39 karolherbst_work: mlankhorst: fun task ain't easy :p
12:40 karolherbst_work: and later we do wayland on uefi :)
12:40 karolherbst_work: :D
12:40 night199uk: karolherbst_work: yeah - you’d need to disconnect the PCI ROM driver
12:40 night199uk: it would be problematic
12:42 karolherbst_work: I am sure it is quite possible
12:58 hakzsam: imirkin, just tested heaven+tess on gm206 through x11vnc, seems quite nice (no rendering issues), here's some benchmarks http://hastebin.com/menitoxoba.avrasm
13:05 karolherbst_work: hakzsam: which resolution?
13:06 hakzsam: 640x360
13:06 karolherbst_work: but looks good :)
13:06 karolherbst_work: awesome :)
13:06 hakzsam: yeah, it works at least :)
13:07 karolherbst_work: and if we get hands on PMU firmwares and some work, maxwells are also useable for the more heavy workloads :)
13:07 hakzsam: yep
13:38 karolherbst_work: :D so "OpenGL 2016" it is then
13:38 karolherbst_work: ohh wait
13:38 karolherbst_work: that just the to now public name I think
13:40 karolherbst_work: "Windows driver version 369.00 and Linux drivers version 367.36.02 provide beta support for OpenGL 2016 ARB extensions on capable hardware." well well well
14:04 night199uk: karolherbst_work: sorry, got pulled away for work :-)
14:04 night199uk: karolherbst_work: it is possible but it’s probably a whole chunk more work now :-) if someone wanted to do it i’d definitely be supportive and share what i learnt
14:05 night199uk: karolherbst_work: as it stands my uefi gop driver is mostly complete (a few notable gaps) and tested on all the cards i have to hand - GTX980, GTX630 and GTX650Ti - I’m going to try and get a GTX780 and some other cards from the second hand mall this weekend
14:06 night199uk: once i figure out if i can open source it or not maybe others will jump in
14:07 night199uk: karolherbst_work: in theory you’re right, it would be possible though.. just sharing what i think the concerns would be with it - mainly around code size, etc
14:08 night199uk: karolherbst_work: the problem in UEFI will be the PCI Option ROM EFI images are preferenced by the BIOS’ driver model; so you’d have to detach the PCI Option ROM driver (supported already) and then attach your own; this would lead to very slow boot times
14:09 night199uk: otherwise you can blow the Option ROM image into the mainboard BIOS and set it to be preferenced over the PCI Option ROM driver (which is what I’m doing for now for testing) or blow it into the (tiny) space in the card VBIOS
14:10 night199uk: it’d definitely be possible to get something working though
14:10 karolherbst_work: oh, so you do that for work or why wouldn't you be able to open source it?
14:10 night199uk: nah, that’s not my work unfortunately ;-)
14:10 night199uk: this is a side project
14:10 karolherbst_work: so, what stands in the way of open sourceing it?
14:11 night199uk: at the moment it’s a relatively 1:1 reverse of the nvidia GOP ROMs
14:11 night199uk: i took various nvidia GOP ROMs and figured out the GOP driver structure they used, reversed them back to C and essentially rebuilt the (modular) tree to support all cards
14:12 karolherbst_work: mhhh
14:12 night199uk: which is i guess how nouveau started?
14:12 karolherbst_work: I doubt that
14:12 karolherbst_work: usually you do black bock REing
14:12 karolherbst_work: otherwise you run into legal issues at some point
14:12 night199uk: right - hence the problem :-)
14:12 karolherbst_work: well
14:12 karolherbst_work: it also means, that you as a person are marked :p
14:13 night199uk: haha
14:13 karolherbst_work: no kidding
14:13 karolherbst_work: you should read about the stuff of wine
14:13 karolherbst_work: if you ever worked for MS, you are out of the game
14:13 night199uk: ?
14:13 karolherbst_work: if you ever saw MS code
14:13 karolherbst_work: also out
14:13 karolherbst_work: for life
14:13 night199uk: got a link on the wine stuff?
14:13 karolherbst_work: disassembling is a corner case somehow
14:14 night199uk: well, i never saw any nvidia code
14:14 karolherbst_work: yeah, disassembling is cricitcal
14:14 karolherbst_work: because it is the same somewhat
14:14 karolherbst_work: with limits
14:14 karolherbst_work: night199uk: https://wiki.winehq.org/Developer_FAQ#Who_can.27t_contribute_to_Wine.3F
14:15 karolherbst_work: disassembled is also not allowed for wine as it seems
14:17 night199uk: interesting
14:17 night199uk: but; nouveau had some element of reversing, right?
14:17 night199uk: https://nouveau.freedesktop.org/wiki/REnouveau/
14:18 mupuf: yeah, but that is black-box
14:18 mupuf: we send commands and see what goes out
14:18 mupuf: this is of course legal
14:18 night199uk: ahhh
14:18 night199uk: got it
14:18 night199uk: it’s a real grey area
14:18 mupuf: disasming only happened for the context switching firmwares ... because there is no way around
14:19 mupuf: and if so, it is legal in europe
14:19 mupuf: not in the US though
14:19 night199uk: so there was some disasming?
14:19 night199uk: yeah
14:19 night199uk: well, its not illegal here either :-)
14:19 mupuf: not of the cpu driver
14:19 night199uk: has anyone here ever had the discussion with nvidia?
14:20 mupuf: they said they would not help nor hinder us ... now they are helping us
14:20 night199uk: pragmatically people have released reverses of a bunch of different stuff now - the reverse of the mac boot.efi bootloader still sits on github
14:20 night199uk: and, there is nothing in the UEFI GOP driver that isn’t already in nouveau really
14:20 night199uk: its a basic 2d framebuffer driver
14:20 mupuf:had a phone interview with them and they don't seem that secretive for this kind of things
14:20 night199uk: so there are many implementations in the PD already
14:21 mupuf: they just don't see the value of open sourcing becuase clients don't ask for it
14:21 night199uk: sure
14:21 night199uk: maybe i’ll just open source it and take the chance
14:22 night199uk: there is nothing ‘new’ or groundbreaking or particularly proprietary there
14:22 night199uk: even if they did something there is probably a defence that 99.9% of it is already in the public domain i guess
14:23 mupuf:will refrain from giving legal advices
14:23 night199uk: hehe, yeah
14:23 mupuf: logic in this world is ... what the fuck?
14:23 night199uk: well, i’m going through tidying up and renaming a lot of unnamed stuff (hence all the questions) now
14:24 night199uk: then i can figure that out afterwards
14:25 karolherbst_work: night199uk: it isn't a grey area, black block REing is legal
14:26 karolherbst_work: no buts (except wtf moments)
14:26 night199uk: depending on your country
14:26 karolherbst_work: nope
14:27 karolherbst_work: it can't be illegal, because it would have severe effects
14:27 night199uk: right, yer
14:27 night199uk: i was talking about disassembly
14:27 karolherbst_work: imagine this: you get a new machine (imagine a car is new) and you figure out, if you press the pedal, it accelerates
14:27 night199uk: yup
14:27 karolherbst_work: and you figure it all out
14:27 karolherbst_work: like, stronger pressing, more speed
14:28 karolherbst_work: if black box REing would be illegal, you wouldn't be allowed to talk about the pedal thing to anybody
14:28 karolherbst_work: or you won't be able to build a device, which also has a pedal to accelerate
14:29 karolherbst_work: that is what patents are for then :p
14:29 night199uk: heh
14:32 l1k: night199uk: link for the mac boot.efi bootloader?
14:32 l1k: FWIW German law specifically allows "decompiling" under certain circumstances: http://www.gesetze-im-internet.de/englisch_urhg/englisch_urhg.html#p0453
14:33 karolherbst_work: the problem is of course the "under certain circumstances" part
14:33 karolherbst_work: so, basically it is still illegal :p
14:33 karolherbst_work: (depends on how much you spend on the lawyer though)
14:34 l1k: the certain circumstances refer to attaining interoperability, so no it is not illegal.
14:35 karolherbst_work: that's the problem though
14:35 karolherbst_work: maybe it isn't required that you obtain interoperability this way
14:35 karolherbst_work: then what?
14:36 karolherbst_work: this law is for like stuff, which isn't supported anymore
14:36 karolherbst_work: or there is no documentation
14:36 karolherbst_work: it's a practically useless law for most use cases
14:37 karolherbst_work: you can't decompile the windows kernel with that
14:37 karolherbst_work: because the API you need is usually accesable
14:37 l1k: the bar is not if it's required. you are allowed to disassemble if your goal is to achieve interoperability, e.g. with a different program.
14:38 karolherbst_work: and then you are only allowed to decompile kernel APIs with no documentation
14:38 karolherbst_work: try to tell them, how you didn'T decompile more
14:38 karolherbst_work: read the first thing again
14:38 karolherbst_work: "indispensable to obtain the information necessary to achieve the interoperability"
14:38 karolherbst_work: "indispensable"
14:38 karolherbst_work: that's the bs word here
14:39 karolherbst_work: and breaks anything
14:39 night199uk: indeed
14:39 night199uk: but that is specifically for someone working on an independently created program
14:39 night199uk: and is limited to the parts required to achieve interoperability
14:39 night199uk: so probably wouldn’t apply
14:40 karolherbst_work: it never applies if your opponent has a expensive lawyer :p
14:40 karolherbst_work: in doubt you loose with that in court, so I wouldn't really be happy to rely on that
14:41 karolherbst_work: the second part is bs even more
14:41 karolherbst_work: because you can't tell anybody, except they also need it
14:41 l1k: night199uk: once again, do you have a link to boot.efi for the mac on github?
14:41 night199uk: l1k: i
14:41 night199uk: l1k: i’ll dig it out
14:42 night199uk: l1k: on a work call, will ping it to you
14:45 karolherbst_work: ohh nice, decompiling isn't legal in the entire EU, nice
14:45 karolherbst_work: (with exceptions)
14:50 night199uk: i *think* this is the original
14:50 night199uk: https://code.google.com/archive/p/macosxbootloader/source
14:51 night199uk: this is a derived work
14:51 night199uk: macosxbootloader
14:51 night199uk: oops
14:51 night199uk: https://github.com/Piker-Alpha/macosxbootloader
14:51 l1k: yes I know that one.
14:51 night199uk: thats derived from the original
14:52 karolherbst_work: MSVC required .D
14:52 karolherbst_work: :D
14:53 karolherbst_work: funny
14:53 night199uk: heh
14:53 night199uk: yeah, this is the original
14:53 night199uk: code.google.com/p/macosxbootloader
14:54 night199uk: can make it build with GCC & CLANG :-)
17:19 mupuf: mwk: http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-RISC-V-Next-Gen-Falcon
17:28 mupuf: what the heck! Falcon is out of order execution!
17:29 mupuf: karolherbst: http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-RISC-V-Next-Gen-Falcon
17:29 karolherbst: somebody already mentioned this earlier
17:30 mupuf: lol, it is going to be a dual core :D
17:30 karolherbst: :O
17:30 karolherbst: each?
17:30 mupuf: well, good question, I doubt it
17:30 mupuf: pdaemon does not need speed
17:30 karolherbst: mhhh, why?
17:30 mupuf: there is going to be falcon + a RISC V
17:30 karolherbst: I know it shouldn't be slow, but ...
17:30 karolherbst: yeah, I know
17:30 mupuf: well, because it will take time to port the code :D
17:31 karolherbst: this is nothing new for me :p
17:32 mupuf:was late
17:32 karolherbst: I bet RSpliet told us all about their plans
17:35 karolherbst: mupuf: http://www.lowrisc.org/blog/2016/07/notes-from-the-fourth-risc-v-workshop/
17:37 mupuf: hopefully, they will keep the ISA mostly compatible with RISCV and we will be able to use all the existing toolchain
17:37 karolherbst: well
17:37 karolherbst: you forget about something, do you? :D
17:38 mupuf: what?
17:38 karolherbst: I doubt they will stop to secure their stuff
17:38 mupuf:wonders what new application requires such an improvement in perf
17:38 mupuf: oh, right :D Silly me :D
17:38 karolherbst: :D
17:38 karolherbst: well
17:38 karolherbst: improved nvenc?
17:39 karolherbst: 4k realtime encoding
17:39 karolherbst: or is it already possible?
17:39 mupuf: yeah, 4K may be an issue
17:39 karolherbst: then 4k@ 144 fps!
17:39 karolherbst: I am sure the current nvenc is already a beast
17:39 mupuf: already done
17:39 karolherbst: ohh
17:40 karolherbst: pascal supports 8k :O
17:40 mupuf: pascal has 4K@120fps
17:40 karolherbst: crazy
17:40 imirkin_: can't even do 144hz?
17:40 imirkin_: what a piece of junk!
17:40 karolherbst: :O what a trash
17:40 mupuf: hehe
17:41 imirkin_: i can do that with pen and paper!
17:41 imirkin_: in my sleep!
17:41 mupuf:also does not really get the OS support
17:41 gregory38: maybe hpc stuff
17:41 mupuf: maybe they want to ditch their weird RTOS in favor of freeRTOS or anything related
17:41 karolherbst: maybe
17:41 mupuf: gregory38: it would make no sense :D
17:41 karolherbst: or it is just a hacky thing
17:41 karolherbst: or maybe they want to move the driver on the gpu!
17:41 imirkin_: gregory38: falcon isn't used for computation
17:42 imirkin_: gregory38: it's a service cpu
17:42 mupuf: karolherbst: that would be something I predicted in my PhD thesis :D
17:42 karolherbst: :D
17:42 karolherbst: they stole your idea
17:42 mupuf: not everything, but a lot of it
17:42 gregory38: yes but hpc typically need big GPU for computation and a small service CPU to transfer the data
17:42 mupuf: lol, as if
17:42 karolherbst: mupuf: you should make a patent fast :p
17:42 mupuf: gregory38: this is already present
17:42 mupuf: there are many copy engines
17:43 mupuf: and falcon is not a performance issue there
17:43 karolherbst: maybe with pascal those falcons are simply too slow now
17:43 imirkin_: those used to be falcon on fermi, but now are no longer user-accessible
17:43 karolherbst: overall
17:43 mupuf: or it becomes one ... with HBM
17:43 mupuf: imirkin_: really? PCOPY is programmed how then?
17:44 imirkin_: mupuf: it's part of PFIFO now
17:44 mupuf: fun
17:44 imirkin_: starting with kepler
17:44 imirkin_: still a different class for it, of course
17:44 mupuf: hehe
17:44 imirkin_: but afaik it's serviced by the fifo engine
17:45 imirkin_: (and m2mf is entirely gone too)
17:45 imirkin_: or ... hm. i could be wrong.
17:45 imirkin_: it might be a separate engine still
17:45 imirkin_: yeah, coz there are multiple ones
17:45 imirkin_: i'm thinking of p2mf which is serviced by pfifo
17:46 mupuf: ok, I guess I need to consider that I do not know anything on memory manahgement on kepler+
17:47 pascalnv: https://developer.nvidia.com/nvidia-video-codec-sdk
17:47 pascalnv: "HEVC 8K (8192 pixels x 8192 pixels) encoding * HEVC 4:4:4 encoding * HEVC 10-bit encoding * HEVC lossless encoding * HEVC Sample Adaptive Offset (SAO) * HEVC Motion-Estimation-(ME)-only mode * HEVC (up to 8K) decoding * VP9 (up to 8K) decoding *"
17:47 pascalnv: "* These features require Pascal generation GPUs."
17:47 pascalnv: Pascal is a beast in media decoding & encoding
17:53 gruetzkopf: nice
17:54 imirkin_: doubt you'll be seeing nouveau drive any of that anytime soon
17:55 pascalnv: http://us.download.nvidia.com/XFree86/Linux-x86_64/367.35/README/vdpausupport.html "GPUs with VDPAU feature set G support all of the same VdpDecoderProfile values and other features as VDPAU feature set F. In addition, these GPUs have hardware support for the HEVC Main 12 profile." "GPUs with VDPAU feature set H support all of the same VdpDecoderProfile values and other features as VDPAU feature set G."
17:55 pascalnv: Pascal is Feature Set H hardware decoder
18:26 mwk: imirkin_: p2mf is a PGRAPH class, actually
18:26 imirkin_: mwk: hmmm ... relaly?
18:26 imirkin_: am i just totally confused?
18:26 mwk: yeah
18:26 imirkin_: excellent.
18:27 mwk: it goes through the PGRAPH frontend
18:27 mwk: ie. you can't use it in parallel with 3d/2d
18:27 mwk: oh, and it supports macros as a consequence
18:29 mwk: as for copy PCOPY engines, they are actually still alive and not very different from Fermi... except the falcon controlling them is gone, and replaced with custom logic in PFIFO
18:32 mwk: and P2MF... it's PGRAPH, but it's a separate hw engine in many ways
18:33 mwk: basically the PGRAPH frontend can be configured to submit the processed commands to either the main 2d/3d/compute unified pipeline, or to the P2MF block
18:34 mwk: loading the 2d/3d/compute classes flips the switch to the main pipeline, loading the P2MF class flips it to the P2MF
18:35 mwk: and it's been that way since Tesla (where it was M2MF, not P2MF)
18:36 imirkin_: do you use earplugs to avoid letting this stuff leak out from your head? :)
18:38 mwk: nah, stopping the leaks is not enough, I sleep with headphones set to play the nvidia drivers as raw PCM audio every night to actively push things in
18:38 mwk: lets me decompile in my sleep
18:39 imirkin_: hehehe
18:44 mwk: and in unrelated news
18:45 mwk: is anyone opposed to switching envytools from C to C++11?
18:45 mwk: nobody? good, transition begins in 15 minutes
18:45 Tom^: =D
18:45 imirkin_: hmmmm... might be nice to leave a C api for rnn. dunno.
18:46 mwk: well, I'm not going to actually rewrite things, just change the file extensions to .cc and compile as C++
18:46 mwk: use it for new code
18:47 mwk: so if we need some existing stuff as C APIs, it's as simple as stuffing them in extern "C" {}
18:47 imirkin_: ye
18:49 mwk:really hopes hwtest can be unuglified with proper use of classes
18:50 mwk: and initializer lists, that has to be the best C++11 feature
18:52 hakzsam: auto is nice sometimes too :)
18:54 imirkin_: yeah. auto and initialiser lists are my favourites
18:54 hakzsam: while lambda functions are sooo ugly in my opinion
18:56 mwk: ugly, but still much better than not having them
18:57 hakzsam: depends on how you use them actually
18:58 karolherbst: mhh, in life is strange I get screen tearing over prime :/
19:02 maleadt: hi all, quick semi nouveau-related question: I was looking into rr (mozilla's record replay) support for CUDA applications, which needs to know about ioctls in order to make them deterministic
19:02 maleadt: so I found the ioctl definitions for /dev/nvidiactl in envytools/demmt, but when inspecting a trace with valgrind-mmt it looks like there's stuff happening on /dev/nvidia-uvm too
19:03 maleadt: have these been reverse-engineered as well?
19:03 karolherbst: hakzsam: did you start that one list with the games running well with nouveau?
19:04 hakzsam: karolherbst, yeah, "started" is the word ;)
19:04 hakzsam: https://nouveau.freedesktop.org/wiki/GameDatabase/
19:05 karolherbst: still have now wiki account :/ anyway, you could add life is strange to the list as running good
19:05 karolherbst: ~45 fps on highest settings ony my 770m fully reclocked
19:05 karolherbst: no clue compared to nvidia though
19:06 hakzsam: you can update the page if you want
19:06 karolherbst: guess why I said "still have now wiki account" :p
19:06 karolherbst: otherwise I would have already
19:07 karolherbst: Team Fortress 2 randomly hangs my GPU though
19:07 karolherbst: sometimes after 1 hour, sometimes after 4 or 5
19:07 karolherbst: couldn't debug the cause
19:07 imirkin_: 4-5h playing TF2? i think nouveau's doing you a service
19:08 imirkin_: it's a "time to stop" indicator
19:08 hakzsam: hehe
19:08 hakzsam: I have tested it few minutes only :)
19:08 hakzsam: it didn't crash, so -> it works
19:08 hakzsam: nice assumption, right?
19:09 hakzsam: imirkin_, did you see my message about heaven+tess on gm206, btw?
19:09 karolherbst: imirkin_: huh? :O
19:09 karolherbst: I consider a crash after 5 hours as bad
19:16 hakzsam: it's not cool, but really not critical, playing 5 hours without a crash is very nice IMO
19:16 karolherbst: that's pretty normal for me though
19:16 hakzsam: sometimes games crash at startup... :)
19:16 karolherbst: :D
19:16 karolherbst: I usually try to fix those issues :p
19:17 hakzsam: but hard to track down
19:17 karolherbst: sometimes, yeah
19:17 karolherbst: but mostly the things I messed with, were stuff like missing extensions or stupid behaving engines
19:17 hakzsam: okay
19:18 karolherbst: divinity OS was fun to track down
19:18 hakzsam: but well, when a game crashes after few hours I would say it's because we don't reset some states properly at some point
19:18 hakzsam: which is hard to fix
19:19 Calinou: some people wanted to run Doom for 4 years continuously to trigger a bug
19:19 Calinou: :]
19:19 karolherbst: :D
19:19 hakzsam: some people are crazy :)
19:19 gruetzkopf: 32bit integer frame counter?
19:19 karolherbst: Calinou: not even zOS is made for that :p
19:20 karolherbst: *z/OS actually
19:21 karolherbst: let's how long life is strange runs today :)
19:22 Calinou: gruetzkopf: 32-bit integer counter for berserk color
19:22 Calinou: if you run it for more than 4 years, screen turns permanently red
19:22 hakzsam: fun
19:25 hakzsam: karolherbst, did you already try F1 2015 btw?
19:26 karolherbst: don't have it
19:26 karolherbst: ohh wait
19:26 karolherbst: no, I didn't
19:26 hakzsam: with nouveau's account?
19:26 karolherbst: yeah, sadly not family shareable
19:27 karolherbst: ohh wait
19:27 karolherbst: mhh, it isn't in the list
19:27 karolherbst: let me check
19:27 karolherbst: or did you mean dirt?
19:27 hakzsam: I have a key for that game, but I don't even steam installed here
19:27 karolherbst: or grid
19:27 hakzsam: nope, F1
19:27 karolherbst: mhh
19:27 hakzsam: grid autosport is a different game
19:28 hakzsam: well, short storr, F1 totally hangs the gpu both on fermi and kepler, it has to be fixed at some point
19:28 karolherbst: mhh, there is no f1 on the account
19:28 hakzsam: but it's not going to work on fermi for a while because it uses more than 16 texture handles
19:28 hakzsam: okay
19:29 hakzsam: oh I have a trace
19:29 hakzsam: karolherbst, https://people.freedesktop.org/~hakzsam/f12015.dump
19:29 hakzsam: be careful :)
19:29 hakzsam: oh no, it's a dump grrr
19:29 karolherbst: :D
19:30 karolherbst: if somebody wants to check the liveOnly thing: https://github.com/karolherbst/mesa/commit/e86b5c86b19978b3f839073ec6ee3a8f522b328d
19:30 hakzsam: well, I don't have it here sorry
19:30 karolherbst: it hangs some games
19:30 karolherbst: no idea why
19:31 karolherbst: improves perf in furmark by 15% though
19:32 karolherbst: and it is recursive, which sucks
19:33 imirkin_: hakzsam: yes, i did
19:33 hakzsam: okay
19:57 karolherbst: mhh, maybe not having a display on the gpu at all makes things a lot more stable than usually
19:57 karolherbst: really can't complain about any unusual crashes overall
20:02 karolherbst: who could again add wiki accounts to fdo? mupuf, can you?
20:03 hakzsam: I think mupuf yeah
20:04 karolherbst: I think mupuf and I tried it once to add an account for me, but somehow it didn't work out
20:10 karolherbst: always fun doing that
20:12 inglor: thesis read -> always good bed time story...
20:12 inglor: thanks for the links I will try read something.
20:17 inglor: mupuf: when was this thesis published?
20:19 hakzsam: ~1.5 years ago
20:20 karolherbst: so, we should discuss XDC at some point, do we want to target that for next month? No idea how active I can be in September actually
20:20 karolherbst: might become a bit more critical time work related
20:24 karolherbst: "Proposals due: Wednesday 17 August 2016 17:00 UTC." uhhhh, good to know actually
20:24 hakzsam: maybe we should discuss with emails!?
20:25 karolherbst: I guess so
20:25 karolherbst: I am not really the email kind of person :/
20:25 hakzsam: yeah, but different timezones
20:25 karolherbst: yeah, I know
20:26 karolherbst: but I also wanted to make a talk on the gpu boost stuff and things
20:26 karolherbst: and I guess the nouveau status talk also needs this 250-1000 word abstract paper done?
20:26 hakzsam: go ahead
20:27 hakzsam: nope, only few lines
20:27 hakzsam: it's a status update
20:27 karolherbst: I see
20:27 karolherbst: while you are having fun the next days, I will write my abstract then :p
20:27 hakzsam: and the nouveau is msot likely going to be accepted :)
20:27 hakzsam: +talk
20:28 karolherbst: well, the talk can be done after the 17th
20:28 karolherbst: I think
20:28 hakzsam: sure
20:28 karolherbst: I am also more worried about the abstract anyway :/
20:29 inglor: when a card has 2x 8pins it means i can draw up to a max of 75W + 150W + 150W power?
20:29 hakzsam: the abstract is just for scheduling the different talks
20:29 karolherbst: should really write more stuff in general
20:29 karolherbst: sure, it just pains me to write stuff :D
20:30 karolherbst: inglor: exactly
20:30 hakzsam: writing an abstract should be done in less than 1h ;)
20:30 urjaman: okay this is maybe a little weird, but would someone have on their mind how to start firefox or chrome with all the GL stuff off?
20:30 karolherbst: hakzsam: make it a day for me :p
20:30 karolherbst: urjaman: check the docs of those applications?
20:30 hakzsam: it's a good exercice
20:30 karolherbst: sure, I have no issues giving a talk or something
20:31 urjaman: yes, i will, once i get access to them, with them being a black box ...
20:31 karolherbst: that's actually something I kind of like to do :D
20:31 urjaman:will use links -.-
20:31 inglor: urjaman: for FF https://support.mozilla.org/en-US/questions/1075185
20:31 karolherbst: I should give more talks, though I am short on topics now, maybe more luck next year
20:32 hakzsam: one is enough :)
20:32 hakzsam: you could make an update at fosdem as well
20:32 urjaman: yes, that link is very not useful
20:32 urjaman: given how firefox is an unusable black box
20:32 karolherbst: hakzsam: yeah, good idea actually
20:36 urjaman: okay, got firefox working ... the preferences in the profile are in prefs.js
20:41 urjaman: anyways, i was just curious to see what'd happen if i plugged this PCI FX5500 in... yeah an NV34 isnt that good with the forced GL-enable settings in my browsers :P
20:42 imirkin_: urjaman: yeah, it's not ideal. i try to support it reasonably... have one plugged in
20:43 imirkin_: but i doubt a ton of people test firefox with a GL 1.5 renderer
20:45 inglor: what's the diff between GDDR5X and GDDR5 VRAM?
20:46 imirkin_: X
20:46 inglor: really? :O
20:51 urjaman: for chrome... ran it in a VNC server to be able to use the UI to turn the accel off :P
21:00 karolherbst: inglor: it's faster
21:01 karolherbst: and somehow complicated in design, I fear that we get 4 staged clocks with GDDR5X :/
21:01 karolherbst: life is strange running for 135 minutes now :p
21:06 RSpliet: mupuf: RISC-V has a very elaborate "ISA extension" scheme
21:07 RSpliet: so undoubtedly they'd extend the ISA for I/O space transfers, vdec-specific insns, timer stuffs...
21:07 RSpliet: so you get the toolchain for free (opcode format, control flow, basic arith+mmio), and only need to figure out NVIDIA-specific bits
21:08 RSpliet: I have not spoken to the particular engineer yet, but it'd be interesting to hear more from him
21:31 urjaman: oh, now i'm curious, why 1.5 ? (wikipedia lists the FX series with OpenGL 2.1, so is that just blob doing more than what the cards can really do, or ...?)
21:32 imirkin_: blob is providing fallbacks for some things
21:32 imirkin_: afaik as soon as you fall off the fastpath, you're in swrast land
21:32 imirkin_: so you gotta be careful
21:32 imirkin_: it can do a lot of GL 2.1 though
21:32 imirkin_: just ... not everything
21:32 imirkin_: like non-power-of-two textures, if you want working texture wrapping
21:37 urjaman: yeah one weird thing, this thing barfed with IOMMU enabled
21:38 urjaman: kernel started and it was just an infinite scroll of AMD-Vi something something page fault something, and i made a guess and turned off IOMMU and it started fine...
21:38 imirkin_: iirc that's common
21:41 urjaman: yeah i guess i'll leave this in for a while... I've had the system crash with the 9400 GT in weird ways, sometimes totally (not even sysrq alive), sometimes with just graphics frozen, sometimes the mouse cursor still worked but nothing else (and audio and ssh etc)...
21:42 urjaman: so i put this in as the next thing on the table, just to see whether it is ever the CPU failing...
21:44 imirkin_: nouveau has some issues with tesla's
21:47 karolherbst: I guess nouveau does really good for life is strange
21:47 hakzsam: nice
21:47 karolherbst: 182 minutes up
21:47 karolherbst: and stable 40fps+
21:48 karolherbst: on maxed out settings
21:48 hakzsam: :)
21:48 karolherbst: 640 is minimum requiernment
21:49 karolherbst: nice game by the way :)
21:49 karolherbst: ohh, they did test with mesa 11.2 on AMD and intel
21:51 karolherbst: ohh right, feral ported it :)
21:52 karolherbst: they seem to do a very good job in general
21:58 karolherbst: game seems to be highly memory bottlenecked
21:59 karolherbst: so no issues in the compiler as well :p
21:59 imirkin_: at least insufficiently visible issues :)
22:00 karolherbst: right
22:30 karolherbst: my EC is just shit :/ I am soo looking forward buying me a new computer and all :/
22:36 mwk: wheee
22:36 mwk: I finally figured out how VGA text mode works on NV1 :)
22:38 mwk: so the scanout hardware doesn't understand VGA at all, it can only beam raw 8bpp/16bpp/32bpp pixels to the DAC
22:39 mwk: but there's a special text-rendering engine, PRM, which reads the VGA memory and renders text to another area of VRAM, which is then displayed by scanout
22:40 mwk: and only just enough of VGA registers to implement text rendering are implemented in hw
22:40 mwk: ... for the common cases
22:41 mwk: the uncommon cases, like non-standard palette index assignments in attribute controller, are just not implemented
22:42 mjg59: mwk: I thought *I* spent my time poorly
22:42 mwk: except it kept rendering a 640×256 pixels image, I spent hours trying to bash PRM registers to get it to render 640×400
22:43 mjg59: mwk: So it doesn't support VGA graphics mode?
22:43 mwk: in the end it turned out it just took the destination height from the *scanout* height register, despite it being a whole distinct hw block
22:43 mwk: and I set my scanout to 1024×768, which is of course 256 lines because PRM only steals 9 bits of height from scanout config...
22:44 mwk: mjg59: that's a good question, isn't it...
22:44 mwk: I think it does, actually
22:45 mwk: it has to support 640×480×4 at least, otherwise you can't boot windows 95 before drivers are installed, and everything is horrible
22:45 mjg59: mwk: Right, that was what I thought
22:45 mwk: except, I can't figure out how to get the damn thing to work
22:46 mjg59: And I thought a bunch of stuff still assumed VGA registers even if you'd set a VESA mode
22:46 mwk: the scanout and DAC both have a 4bpp mode
22:46 mwk: and if I set it... well, I clearly do get a 4bpp mode
22:46 mwk: with VGA planar pixel format, even
22:47 mwk: but... it appears I get a random palette
22:47 mjg59: Is it the Windows 95 palette
22:47 mwk: as in, completely random, but constant
22:47 mwk: no
22:47 mjg59: Because that would have been terrifying
22:47 mwk: color 0 is pink, for fuck's sake
22:47 mwk: and there is no black in the palette, or white, or anything sane
22:47 urjaman: is that the 4 color CGA palette?
22:48 urjaman: okay no :P
22:48 mwk: it's just 16 const colors that I can't change in any way
22:49 mwk: the VGA palette appears to be completely ignored, I've set it to all-0
22:49 urjaman: oh yeah that one doesnt have "pink" as 0 anyways ...
22:49 mwk: so... I'm lost
22:50 mwk: clearly the DAC knows VGA pixel format, it just pulls a palette out of nowhere
22:51 mwk: of course on an actual VGA-compatible, the scanout would have converted the VGA planar pixels to 8-bit indices for the DAC, but this doesn't happen here...
22:52 mwk: if I misconfigure the scanout to 8bpp and DAC to 4bpp, the pixels are intepreted as 4bpp VGA planar, so it's definitely DAC doing the parsing
22:52 mjg59: mwk: Tried setting a vesa mode with vbetool and then seeing whether the palette works?
22:52 mwk: mjg59: there's a problem... my NV1 for some strange reason came with a broken VBIOS, I can't boot the card in a normal way
22:53 mwk: I had to write my own program to POST it from linux
22:57 hakzsam: I have just submitted a series which exposes GL 4.1 on Maxwell :)
22:57 mjg59: mwk: Ha
22:58 mwk: eh, who knows
22:59 mwk: maybe I'm so unlucky, it also comes with a defective DAC where the exact pathway used for 4bpp display is burnt or something
22:59 airlied: mwk: the radeon didn't do that sort of text mode emulation until r500 :)
22:59 mwk: airlied: and nvidia still doesn't, AFAIK
22:59 mwk: as in, nvidia other than NV1 :)
23:00 mwk: anyhow
23:00 mwk: clearly the damn thing should be able to support VGA 4bpp
23:01 mwk: it has all the VGA registers controlling the weirdo planar memory read/write modes
23:01 mwk: and they even appear to work
23:02 mwk: scanout is able to beam 4bpp, DAC is able to parse 4bpp, it just fails on the palette
23:02 mwk: it may not support CGA graphics modes, but oh well, who uses those...
23:03 mjg59: Found a machine with VLB graphics a couple of weeks ago
23:03 mwk: hmm actually
23:04 mjg59: First time I'd ever seen one in real life
23:04 mwk: the GC register enabling that mode *is* implemented, let's see...
23:04 airlied: wow vlb
23:04 mwk: mjg59: never seen one :(
23:05 mjg59: You're not missing out
23:05 mwk:heard there were VLB NV1's
23:05 mjg59: Orly
23:05 mwk: not from a very reliable source, but oh well
23:06 mwk: well, at least the NV1 chip had the capability to connect to VLB as well as PCI, I have no idea if they ever actually made a board
23:06 mwk: I actually found a datasheet for that thing, old times :)
23:06 mwk: it even documented a grand total of 1 MMIO register!
23:08 mwk: nah, CGA 2bpp graphics doesn't work, the GC reg bit doesn't do anything
23:08 mwk: probably for the best...
23:12 imirkin_: wasn't vlb made precisely for graphics cards?
23:12 imirkin_: the agp of its day
23:12 imirkin_: when eisa just isn't godo enough
23:14 imirkin_: and you're not ibm so you don't want to use mca :)
23:15 mwk: yeah well... VLB is not really a new bus, it's just the 80486 memory interface hammered into a connector
23:16 mwk: posing certain obvious problems if your CPU happens not to be an 80486
23:16 imirkin_: .... can't think of any ;)
23:18 imirkin_: as if there will be a cpu after the 80486
23:18 imirkin_: that's just crazy-talk
23:19 imirkin_: they did milk it for a while... SX, DX, DX2, DX4... (was there a DX3? iirc there were 75mhz ones...)
23:20 urjaman: this laptop here has a 25Mhz SL, which is kinda like a DX (=has FPU), despite the S in the name...
23:22 mwk: eh
23:22 mwk: maybe I'll just power off this machine and go to sleep
23:23 mwk: and when I wake up and power it on again, whatever weirdo register that holds the mysterious 4bpp palette will have a different value
23:24 mwk: I mean, there has to be a register somewhere that I'm missing, it's not like they hard-wired this pink palette
23:24 mjg59: imirkin_: DX4 was actually clock tripled
23:24 mjg59: imirkin_: The DX4 100 was a 33MHz bus
23:25 mjg59: So no DX3
23:26 imirkin_: oh right.
23:26 urjaman: wouldnt DX3 then be clock 2.5'd ? ... whatever :P