01:40 Horizon_Brave: hey folks
05:35 Teklad: Oi
06:14 leberus: mupuf_: Hi! I've sent the patches to dri-devel@lists.freedesktop.org and to nouveau@lists.freedesktop.org. The first one of the series is here: https://lists.freedesktop.org/archives/dri-devel/2017-April/139310.html
06:16 leberus: and here for nouveau lists: https://lists.freedesktop.org/archives/nouveau/2017-April/027733.html
06:16 leberus: :)
06:16 leberus: so i guess they reached the mailing lists
07:22 mupuf_: leberus: oh, of course!
07:22 mupuf_: I checked the patches, they looked quite good! Your patches just ended up in my dri-devel folder
07:59 karolherbst: leberus: yeah, the series begins to look really good :) I just need to find some time and spend time on the 4/5 patch, because it's quite large. Some smaller nits here and there (and I still want to test every commit on its own)
07:59 karolherbst: leberus: maybe you should do that as well: see if you can access the hwmon entries without issues on each commit
08:24 pmoreau: karolherbst: I am at the computer, if you have some thing to try.
08:25 karolherbst: pmoreau: run nvidia-smi with this: https://gist.github.com/karolherbst/100c7364453ddc628ab62f3fb503dc59
08:25 karolherbst: just like in the comment
08:26 pmoreau: Ok
08:27 pmoreau: Might want to adjust the comment so that the filenames match with the name of your gist
08:28 pmoreau: That way, one can be lazy and just copy/paste the comments to run it :-D
08:29 pmoreau: karolherbst: https://phabricator.pmoreau.org/file/data/53gwgns23q4x25onoryr/PHID-FILE-jaanzm7qv3mlvb3urp2b/debug.log
08:30 karolherbst: thanks
08:31 Teklad: The sweet smell of progress.
08:32 karolherbst: pmoreau: I think the file is in some git repository as well, no clue where
08:32 karolherbst: Teklad: I still think it takes 2 years :p
08:32 Teklad: karolherbst: You ruined my moment. :(
08:33 koz_: Teklad: karolherbst lives to ruin your moments with his pragmatism. :P
08:33 Teklad: 2 years isn't excessively long though really.
08:33 Teklad: Especially not for reverse engineering, lol
08:33 karolherbst: pmoreau: hum :( no more information, oh well. I need to go through those in greater detail
08:33 pmoreau: :-/
08:33 karolherbst: the trace is perfect to re the vpstate table
08:33 Teklad: It took like what... 10 years for the OpenMW project to get to where it is now?
08:33 karolherbst: but I already did so yesterday
08:35 karolherbst: pmoreau: this will be a lot of pain if we don't find a way to upload the vbios on the GPU
08:35 karolherbst: we could always flash the vbios....
08:35 karolherbst: I think
08:36 karolherbst: mhhh
08:36 karolherbst: mhhhhhh
08:36 karolherbst: I think I found a way
08:36 mupuf_: ?
08:36 pmoreau: Yeah, I can get that. But, I won’t be doing any flashing or anything similar on this computer! :-)
08:37 karolherbst: well, there are tools to flash the VBIOS on the GPUs, right?
08:37 mupuf_: speaking about flashing... now that I think of it, we should be able to do pretty safely given that the vbios of the GPU should not be needed for us to overwrite it
08:37 mupuf_: karolherbst: there are
08:37 mupuf_: but windows/DOS only
08:38 mupuf_: I guess this will need to be reverse engineered
08:38 karolherbst: there should be Linux tools as well
08:38 karolherbst: and if not
08:38 mupuf_: but it still will be encrypted
08:38 mupuf_: err, signed
08:38 karolherbst: we just mod wine so that it thinks the GPU is there
08:38 karolherbst: and we just dump the bytes which would get uploaded
08:38 karolherbst: and upload this with our own tools
08:38 karolherbst: and it is signed most likely this way
08:39 karolherbst: or is there a mistake in my thinking now? We just intercept what those tools would upload and upload this with nvafakebios
08:42 pmoreau: I would assume the signing is not done by the flashing tools, and that the VBIOS they upload has already been signed.
08:45 karolherbst: okay, but there is a tool to modify the vbios
08:45 karolherbst: but I do think it signs the vbios
08:46 karolherbst: pmoreau: always remember, that the overclock lords always find a way to mod their vbios :p
08:47 pmoreau: :-D
08:51 karolherbst: mupuf_: well, I guess it's really fine. We shouldn't be able to brick a GPU by changing something in the vbios, because we usually know what we can change and what not. And if we have two GPUs we can always reflash one
08:57 karolherbst: I guess there are cheap enough Maxwell2 GPUs we could test that stuff on
09:05 karolherbst: oh no :(
09:06 karolherbst: mupuf_: I assume a die shrink is relevant for reclocking? I see that GP107 is 14nm where all the others GP are 16 :(
09:06 karolherbst: I hope that the vbios adjusted everything needed here
09:14 mupuf_: karolherbst: of course they adjusted it, that would stupid otherwise!
09:14 karolherbst: hopefully
09:15 karolherbst: kepler and maxwell are all 28nm, so we can't be sure they really did
09:17 mupuf_: maxwell's voltage went down dramatically
09:17 mupuf_: what voltage is now set on pascal
09:17 mupuf_: ?
09:18 mupuf_: the minimum one being the one of interest
09:18 karolherbst: dunno
09:18 karolherbst: the voltage tables are totally different now
09:18 karolherbst: but they are much much lower
09:18 mupuf_: how low?
09:18 karolherbst: I think most of the GPUs are at 1.5GHz and still below 1.1V
09:20 karolherbst: well, I can concentrate on figuring out the voltage stuff for the first step, should be easy enough
09:22 mupuf_: karolherbst: not so much withtout the hw
09:22 karolherbst: traces should be enough to see where they read it out
09:22 karolherbst: pmoreau: you created a trace of the pascal GPU, right?
09:23 karolherbst: I think I didn't saw one inside the repository
12:01 karolherbst: pmoreau: if you are interested, I put some "vbios.rom.fixed" files into the repository, which can be read with current nvbios. There is still stuff missing to teach nvbios to parse the original files and I couldn't get my head around it, cause the code inside nouveau isn't really understandable here
12:21 pmoreau: karolherbst: I don’t think I created a MMIO-trace of the GP102.
12:28 karolherbst: mhh okay, I thought you did
12:28 karolherbst: do you mind creating one?
12:29 pmoreau: I do, a lot! :-p
12:29 pmoreau: I’ll try to remember doing that before leaving
12:29 pmoreau: One with reclock I gues?
12:29 pmoreau: s/gues/guess
12:50 karolherbst: pmoreau: yes
12:50 karolherbst: I still kind of hope that memory reclocking for GDDR5 is basically the same, cause the tables are also the same
12:50 karolherbst: maybe the imeplemntation changed a little, but well
12:51 karolherbst: with a little bit of luck, it might be not that hard
12:54 karolherbst: mupuf_: well if it isn't too much for you, you can get a pascal. I will get one myself, but not until July
12:58 mupuf_: karolherbst: Yeah, I will get one
12:58 karolherbst: nice
13:00 mupuf_: should I go for the 1050 or the 1060?
13:01 mupuf_: isn't GP107 not supported by the firmwares yet?
13:01 imirkin: i believe there's updated firmware now
13:01 karolherbst: it should be I think
13:02 karolherbst: mupuf_: they are all GDDR5, so I don't care really
13:02 mupuf_: yep, it is there: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=065c85fa4a2343ead20cadfe6138f7716659dfe1
13:03 karolherbst: mupuf_: I will most likely get a non GP107 one
13:03 mupuf_: you want real performance? :D
13:03 karolherbst: yeah
13:03 karolherbst: most likely GP102
13:03 mupuf_: :o
13:03 karolherbst: we will get a 4K display at our living room and want to connect something powerful there
13:03 karolherbst: so
13:04 mupuf_: this is likely what I will get: https://www.verkkokauppa.com/fi/product/23913/hjgmb/Asus-GeForce-GTX-1050Ti-EX-GTX1050TI-4G-4096-Mt-naytonohjain
13:04 karolherbst: you can also get a non Ti one
13:04 karolherbst: the non Ti one has higher clocks
13:04 mupuf_: well, I will check the specs and go for something that makes sense
13:05 mupuf_: for some reason, the non-TI version is not on this website
13:05 karolherbst: you need glasses
13:05 mupuf_: well, there is one
13:05 mupuf_: :D
13:05 karolherbst: two
13:06 karolherbst: three actually
13:06 mupuf_: but they are 2GB of RAM
13:06 karolherbst: right
13:06 karolherbst: that's what the non Ti has
13:06 karolherbst: yeah, get the Ti one :p the non Ti is just stupid
13:06 karolherbst: depends on what youw anna do with it
13:07 mupuf_: well, we'll need to gear up for performance tracking
13:07 karolherbst: I will do that already :p
13:07 mupuf_: so tacking something that users actually have is necessary
13:07 karolherbst: I guess I will buy me a GP102 and a GTX 780 Ti as well, depends what I buy first
13:07 karolherbst: most likely the 780Ti as the first one
13:08 karolherbst: and the GP102 later this year
13:09 mupuf_: ah ah
13:11 karolherbst: the GP102 are still so expensive though :(
13:11 mupuf_: yeah, the GTX 1060 are also quite expensive
13:12 karolherbst: mhh but maybe I go for an AMD one, because it will still take quite a lot of time, until a GP102 makes any sense with nouveau and just buy a really cheap pascal one
13:12 karolherbst: dunno yet
13:12 karolherbst: but I will get the 780 ti for sure
13:13 RSpliet: for REing purposes? I have one in my work desktop PC currently
13:13 mupuf_: that sounds more reasonable!
13:14 RSpliet: or... no, this is the regular 780
13:14 RSpliet: meh
13:14 RSpliet: Or do people actually use GPUs for purposes other than REnig?
13:15 mupuf_: RSpliet: why would anyone do that? :o
13:15 RSpliet: beats me...
13:15 Teklad:has no idea what REing is.
13:15 mupuf_: Teklad: Reverse engineering
13:15 RSpliet: some people just really like Starcraft I've heard
13:16 Teklad: I use my GPU for being able to see things on my monitor.
13:16 Teklad: Its really quite nice.
13:16 mupuf_: Oh, you must be the odd one
13:16 Teklad: mupuf_: You must have text-to-speech and blind typing. :)
13:16 karolherbst: well, my main GPU will still be an intel one
13:16 karolherbst: :p
13:17 mupuf_: Teklad: that was sarcasm / joke on us using GPUs only for reverse engineering
13:17 Teklad: mupuf_: I was also using sarcasm. >.>
13:17 RSpliet: *alexa, tell Teklad how it's done*
13:18 Teklad: I'm just here to make sure karolherbst works to death getting my pascal GPU working. :)
13:18 mupuf_: Teklad: you should try harder at making stupid claims :D
13:18 karolherbst: :O
13:18 mupuf_: Teklad: oh no, don't kill him!
13:18 karolherbst: I counter that by making Teklad work on nouveau instead
13:18 mupuf_: karolherbst: that's the spirit ;)
13:18 RSpliet: Teklad: if the bribe is big enough to make him give his current boss the finger, surely he can be made to work a lot harder
13:18 Teklad: karolherbst: This isn't a negotiation.
13:18 karolherbst: Teklad: like it was on my side
13:19 karolherbst: RSpliet: !
13:19 mupuf_: Teklad and karolherbst, I hereby declare you united by the sacred bound of marriage
13:19 Teklad: RSpliet: I make 28k a year... I'd give my own boss the finger before he would. xD
13:20 mupuf_: more seriously though, hacking should be fun
13:20 mupuf_: when it stops being fun, it becomes a job with no pay
13:20 mupuf_: and that is not acceptable
13:21 karolherbst: true
13:21 karolherbst: Teklad: find a better job :p
13:21 Teklad: karolherbst: I'd love to... and have been trying... but my lack of a degree really bites me.
13:21 karolherbst: mupuf_: you have to ask first though
13:22 karolherbst: Teklad: I have no studies degree, it doesn't matter if you can show usefull stuff instead
13:23 dboyan: btw, any interest in gtx 960? I saw someone at my school selling a second-hand one at around $100
13:23 dboyan: but I don't have a desktop machine in the first place
13:24 karolherbst: selling a 960 for 100$?
13:24 karolherbst: I think we have enough maxwell stuff
13:25 karolherbst: Teklad: and if you can show you worked on open source stuff for example and the guy says "you get less payment cause you have no defree" you just step out of the door, cause he is an asshole
13:25 dboyan: um, I guess I'd wait some time and play with my pascal card
13:26 Teklad: karolherbst: I've been thinking of trying out for that Triplebyte thing... the process sounds interesting if nothing else.
13:26 karolherbst: I guess germany is the only place, where you can expect lower payment without a degree without the hiring people being assholes :D
13:27 karolherbst: Teklad: huh? what'S that
13:27 karolherbst: ... sounds like bad payment
13:28 Teklad: karolherbst: They basically screen candidates and hook them up with software companies if they can pass the interview process.
13:28 mupuf_: karolherbst: france is worse ;)
13:28 karolherbst: mupuf_: in france the payment is always bad :p
13:28 mupuf_: and I have 0 proof for it!
13:28 Teklad: I live in America.
13:29 Teklad: All things are bad here.
13:29 mupuf_: well, that too :D
13:29 mupuf_: so, here we are: 3 men from 3 different countries, claiming that their country is the worst :D
13:29 mupuf_: And having no proof for it!
13:29 karolherbst: I didn'T say it is bad here
13:29 karolherbst: :p
13:29 mupuf_: Aren't we amazing :D?
13:30 karolherbst: I just say you can expect to get lower payment with same claficiation for the same job depending on your degree :p
13:30 mupuf_: well, I could not resist the "yorkshire men" moment!
13:30 karolherbst: ! :p
13:30 mupuf_: karolherbst: yep
13:30 mupuf_: well, in france, you would not even get hired, more likely
13:30 mupuf_: :s
13:30 karolherbst: that's even worse :D
13:30 mupuf_: really?
13:31 karolherbst: no, I was just joking
13:31 mupuf_: well, you were right :D
13:32 karolherbst: but the worst you can do in germany is to have a gap inside your CV: "Oh you didn't do anything for 6 months. Well we don't hire you for that"
13:32 mupuf_: this is commi
13:32 karolherbst: last week in the super market: requiernments for working there: CV without any gaps
13:32 mupuf_: common
13:32 karolherbst: well
13:32 karolherbst: not for bullshit jobs
13:32 mupuf_: oh, that is weird for a super market
13:32 mupuf_: agreed
13:33 karolherbst: yeah
13:33 Teklad: gaps in CV... lol
13:33 mupuf_: well, seems like they can get away with it. The job situation must be dire
13:33 Teklad: Tell them to try working demeaning jobs for a while and see if they don't have gaps in CV.
13:33 karolherbst: I have a 1.5 year big one... :D
13:33 Teklad: Going into work is a nightmare.
13:34 Teklad: I open and scan boxes all day.
13:34 Teklad: nightmare
13:34 karolherbst: took me a week here in Hamburg
13:34 imirkin: karolherbst: wow, seriously? there are so many applicants for serious jobs that they avoid hiring for BS reasons?
13:35 karolherbst: imirkin: for BS jobs, yes
13:35 imirkin: oh, well that makes sense - they can be as picky as they want
13:35 karolherbst: it's germany, not the US :p
13:35 imirkin: there will be 30 more applicants tomorrow anyways
13:35 karolherbst: yeah
13:35 imirkin: but for, e.g., a software engineer job? doubtful.
13:35 karolherbst: most likely not
13:35 karolherbst: depends on the company
13:36 imirkin: like successful vs unsuccessful :)
13:36 karolherbst: my CV was really crappy back then though, or still is in some ways
13:36 karolherbst: imirkin: more like big or small
13:36 imirkin: [the unsuccessful ones being the picky ones, of course]
13:36 Teklad: The funny thing is, things like background checks, previous job experience, etc... are nearly irrelevant in terms of IT fields of work.
13:37 karolherbst: imirkin: the other way around :p
13:37 Teklad: Unless its very specialized... like cisco routers or something.
13:37 karolherbst: Teklad: background checks aren't allowed here
13:37 imirkin: karolherbst: ah, so that's why the big companies fail then?
13:37 mupuf_: karolherbst: then bullshit on your CV then?
13:37 karolherbst: mupuf_: :D why?
13:37 Teklad: karolherbst: They probe your background like you're a 5 year old with something to hide here in America.
13:39 karolherbst: Teklad: the best they can do here is to call the old working place and ask
13:39 karolherbst: but well
13:39 karolherbst: nobody has to answer
13:39 karolherbst: so most don't do it
13:39 Teklad: I'm not allowed to leave the country until I'm caught up on my child support.
13:39 Teklad: Its quite lovely.
13:39 karolherbst: and companies could get sued if they talk bullshit about you then
13:40 karolherbst: ...
13:40 RSpliet: Teklad: https://www.theguardian.com/uk-news/2017/apr/16/baby-us-embassy-interview-visa-esta-terrorist
13:41 karolherbst: RSpliet: you still live there?
13:41 RSpliet: where? UK? Quite
13:42 karolherbst: well you still need some time to move if you don't want to live there alone :p
13:42 Teklad: I had a friend who worked up in Wales for a bit.
13:42 RSpliet: karolherbst: I'm doing a PhD at Uni of Cambridge for the next year and a half, why would I move?
13:44 karolherbst: to flee the economical crisis
13:45 RSpliet: There's no crisis until the ties with the EU are severed
13:45 RSpliet: which will take approximately until I've finished my PhD
13:45 Teklad: RSpliet: Got everyone running on your watch there? :)
13:46 RSpliet: like clockwork
13:47 karolherbst: RSpliet: well, as long as you are prepared :p
13:47 RSpliet: I was born prepared
13:48 RSpliet: Don't forget that both the financial industry and the tech industry need competent CompScis. Even in a case of recession I'm in a good place in the UK.
13:49 karolherbst: the financial industry will move to schottland fully and the tech industry just somewhere else :p
13:49 Teklad: I've met a lot of CS graduates... some are amazingly not so bright.
13:50 Teklad: When I worked in Texas a few were annoyed I had the same job as they did.
13:50 karolherbst: ...
13:50 RSpliet: Austin?
13:50 Teklad: Houston.
13:50 Teklad: I had the option to work in Austin, though.
13:51 karolherbst: some here joke around that to be a real hacker you have to abort your studies, otherwise you are not :p
13:51 RSpliet: Ah. Think highly of UT Austin, so was surprised to hear their graduates are not up to standards
13:51 RSpliet: (Texas State on the other hand is not so impressive :-P)
13:51 Teklad: RSpliet: You'd be surprised at the number of CS students that come into programming channels and/or post freelance jobs to do their school work for them.
13:52 Teklad: Its rather appaling.
13:52 RSpliet: Hahaha, that's ridiculous
13:52 RSpliet: pay terrible money for tuition fees and then terrible money not to learn anything
13:52 Teklad: RSpliet: That was my take on it as well.
13:53 Teklad: A problem with the majority of schools is they teach programming theory.
13:53 Teklad: But no actual practical use.
13:53 karolherbst: how nice does it have to be if you don't have to pay for your studies :p
13:53 Teklad: karolherbst: I'm hoping to land a job without having to return to college.... I really don't want to shell out a crap ton of money for things I already know.
13:55 Teklad: ouch
13:55 leberus__: karolherbst i couldn get my screen session xD. I tested commits 3, 4 and 5. With all of them I could get into /sys/class/hwmon/hwmon0/* i didnt try commit 1 and 2 because they dont change the old code (they just add stuff). But I can test them as soon as I get to my laptop :)
14:00 dboyan: Is drm-next stable enough for some casual usage?
14:00 dboyan:was scared some time ago by drm-tip
14:01 karolherbst: mupuf_: I am sure I asked you already about SHA17? I will buy my ticket soon, so I will be there for sure. If you also want to come and somebody else as well, it might make sense to prepare for a Nouveau tent, but we would need to ask others which would host us
14:02 mupuf_: seriously, I should not say yes again to an event like this. I have been overbooking myself this year...
14:02 mupuf_: and I had basically no time to hack
14:03 karolherbst: :(
14:03 karolherbst: you can hack while on the even, duh
14:04 mupuf_: sure, but what about transport time? :D
14:04 RSpliet: Surely that can't be a problem. It's in bumfuck nowhere NL
14:04 karolherbst: get a laptop
14:04 mupuf_: The good thing is: I have a lot of vacation I need to take
14:04 mupuf_: so, maybe I should take a coding vacation?
14:04 mupuf_: Just stay home for a week and code
14:05 RSpliet: mupuf_: A *Summer of Code*?
14:05 mupuf_: RSpliet: ah ah
14:05 mupuf_: true
14:05 Teklad: I'm taking my coding vacation at the moment.
14:05 Teklad: I spent the first 2 days doing nothing.
14:05 mupuf_: Teklad: ah ah!
14:06 karolherbst: mupuf_: you could come visit me, then we drive to SHA17 together and then you could still have time after it or so
14:06 karolherbst: we just get train tickets with power sockets and RE on the train :3
14:07 mupuf_: well, not sure it is going to be efficient
14:07 mupuf_: REing requires to be in the zone, doesn't it?
14:07 mupuf_: events are great for hacking stuff up
14:07 karolherbst: what do you mean?
14:08 mupuf_: what I mean is that it requires focus to RE properly
14:09 karolherbst: then we book for a silent section of the train
14:09 RSpliet: SHA17 isn't ideal to hack because a) distraction, b) no desktop PC to switch GPUs in
14:09 karolherbst: or get our own section with a little door for us alone :O
14:09 RSpliet: it's good for fun though!
14:09 karolherbst: RSpliet: I thought you were always prepared
14:09 karolherbst: you disappoint me
14:09 karolherbst: laptop, duh
14:10 karolherbst: (s)
14:10 Teklad: Its starting to sound more like a romantic get-away.
14:10 RSpliet: karolherbst: yes, plug in that GTX 780 Ti in your laptop
14:10 Teklad: RSpliet: I'm sure they'll have soldering tools on hand for that.
14:10 karolherbst: RSpliet: I only need ana adapter for that
14:10 karolherbst: *an
14:10 mupuf_: hehe
14:10 karolherbst: I have a MXM slot
14:11 RSpliet: Teklad: surely Mitch Altman is there with plenty of soldering kit
14:11 Teklad: I really need to write a quick hash map implementation for storing xcb atoms.
14:12 Teklad: but I'm feeling so lazy
14:12 Teklad:snores
14:15 Teklad: Should be able to keep lookup times fairly low using buckets... though there's rarely ever a ton of atoms in a session... so I'm probably overthinking it.
14:15 karolherbst: Teklad: keep it simple
14:16 karolherbst: :p
14:16 karolherbst: and do usefull stuff with the time you just saved
14:17 Teklad: karolherbst: I could just use a linked list for it so I can get back to implementing the rendering portions. :p
14:17 karolherbst: RSpliet: ohh, I just saw, it is getting more fun over there for you again
14:52 rxr: hi
14:52 rxr: I just booted Linux on an older MacBook Pro 3,1 since some years and stumbled over nouveau not finding the bios tables
14:53 karolherbst: rxr: dmesg please
14:53 rxr: and thus leaving a non working state
14:53 karolherbst: or the exact error message
14:53 imirkin_: rxr: efi boot?
14:53 rxr: yes
14:54 imirkin_: sounds familiar
14:54 rxr: plenty of old and expried / closed bug reports on the web
14:54 imirkin_: the vbios is supposed to be in ACPI tables
14:54 imirkin_: but only placed there on a "legacy" boot, not an efi boot
14:54 imirkin_: lemme see if i can find the bug....
14:54 rxr: that is how the bug repots soudned
14:55 rxr: https://bugs.freedesktop.org/show_bug.cgi?id=35267
14:55 imirkin_: right.
14:55 imirkin_: so you need to do that. :)
14:55 rxr: can there be anything done to make this work more automated for people out there?
14:55 imirkin_: sure. send a patch when you figure it out.
14:56 rxr: well, i'm a developer, but I do not know nvidia chips, ...
14:56 rxr: what is in this bios tables to start with?
14:56 imirkin_: the vbios contains ... let's just say data that's vital to the driver functioning with the board
14:57 imirkin_: on desktop GPUs, it's contained in the option rom (sorta)
14:57 imirkin_: on laptops, in recent times, it's become very common to place the vbios data into acpi tables
14:57 imirkin_: which is where nouveau loads it from
14:57 imirkin_: however it seems like with efi, that's not there
14:57 rxr: about how many values do we talk?
14:57 imirkin_: eh, like 40-64kb of data
14:58 rxr: the mac driver works somehow, do they hardcode all they need? or find it elsewhere?
14:58 imirkin_: most of it unnecessary
14:58 imirkin_: well, apple only makes N different boards, so perhaps they hardcode it. not sure.
14:58 rxr: well at least their driver works on hackintosh's usually without fiddleing, ...
14:59 imirkin_: hackintosh = osx on regular desktop hw right?
14:59 rxr: if this info is not found on modern efi-only boots, maybe it is worth considering hardcoding these values for the hanful of mac hw?
14:59 rxr: yes, macOS on regular PCs with some efi loading glue, ...
15:00 imirkin_: right. so with a regular desktop board, the vbios is stored on the board.
15:00 imirkin_: the driver must be able to load it (since presumably it's just their regular driver, just with a few apple-specific hacks added in)
15:00 rxr: I guess most user hackintosh on regular notebooks
15:01 rxr: anyway, I given each distro and fdo has an aging / closd bug report maybe it shoudl eventually be solved somehow?
15:01 rxr: if we want more people to be able to use Linux?
15:02 imirkin_: to reiterate, i have no problem with either (a) figuring out the alternate location where the vbios lives in the efi boot or (b) shipping something in linux-firmware assuming you get someone's (apple? nvidia?) consent to redistribute the data.
15:02 rxr: well, given that we probable do not want to talk with apple and nvidia about making our video work
15:03 rxr: how many values are this reallyà can that not be a nice C struct {} with the 5 or so efi model names?
15:03 imirkin_: however as i am not in possession of such a machine, there's only a limited amount of stuff i can do to solve it.
15:03 imirkin_: like i said, it's like 64KB of data.
15:03 rxr: yeah, but it sounded nouveau does not need all of those, ..
15:03 imirkin_: not all. but many.
15:04 imirkin_: even if it's 10%, still a bunch
15:04 rxr: what can I do to scan my system memory for these tables?
15:04 imirkin_: well
15:04 imirkin_: i would (a) do a regular boot and extract the vbios
15:04 imirkin_: so that you know what it's supposed to look like
15:04 imirkin_: grab it from /sys/kernel/debug/dri/0/vbios.rom (or just do an acpidump)
15:05 rxr: there is an patch with some efi based boot workaround:
15:05 rxr: https://bugs.freedesktop.org/attachment.cgi?id=45997
15:06 rxr: https://bugs.freedesktop.org/show_bug.cgi?id=35267#c10
15:06 imirkin_: erm
15:06 imirkin_: and where does grub get it from?
15:07 rxr: ahso, this "kloadbios /boot/vbios.bin /int10.bin" loads it from the fs, damn
15:09 rxr: where in the acpi tables should this usually be?
15:09 imirkin_: oh, btw, nvidia blob doesn't seem to work either, based on the comments in the bug :)
15:09 imirkin_: mmmmm... not 100% sure how acpi tables are accessed. they're either in some well-known memory location, or an SMI of some sort
15:09 imirkin_: but the kernel knows how to do it
15:09 imirkin_: and there's a command called 'acpidump' to dump them out for you
15:09 skeggsb: i'd lay bets on apple having done something bullshit, and it's not possible without hardcoding
15:10 rxr: skeggsb: can you point me to anything I shoudl be looking for or dump?
15:10 skeggsb: (ie. hardcoding DCB/BIT tables)
15:10 imirkin_: skeggsb: and init scripts, dp training, etc?
15:10 skeggsb: all those come under BIT ;)
15:10 imirkin_: fine :p
15:10 imirkin_: oh right. BIT. not BMP.
15:11 imirkin_: too many acronyms.
15:11 skeggsb: one of the early apple boards have a fake vbios image in OF, stripped down to look like a PCI ROM, but has no code, just the tables
15:11 imirkin_: i think my nv34 has that.
15:11 skeggsb: yeah, i think that was the one
15:13 rxr: so anything I can help with dumping?
15:13 nyef: ... I think I have a card like that as well. Horribly truncated-looking BMP image?
15:14 nyef: (The fake vbios in OF, that is.)
15:16 imirkin_: rxr: well, you can look in the acpidump of the efi boot. maybe some efivar? dunno.
15:16 imirkin_: use your developer super-powers to look around :)
15:16 karolherbst: skeggsb: found any time to look over my clocking patches again? On a side note: it doesn't seem like Pascal has cstates like maxwell and earlier had. The Voltage map table is super small
15:17 karolherbst: I think they just do some scaling based on the frequency and allow basically any frequency now
15:17 karolherbst: just a guess, but it kind of looks like this
15:18 skeggsb: karolherbst: no, i haven't yet, i will get to it though, i've been fiddling in that area a bit lately, but haven't had a chance to re-look at the stuff i mentioned on irc a while back
15:18 skeggsb: and yeah, pascal clocks are quite different
15:18 karolherbst: I took a look at the PM_Mode table: https://gist.github.com/karolherbst/d7773130e6758507c96317440f33c9b8
15:19 karolherbst: I think there is a flag to indicate whether the clock needs to be doubled or not
15:19 karolherbst: something like: last byte 01 == no doubling, last byte 03 == doublinh
15:19 karolherbst: *doublinh
15:19 karolherbst: ....
15:19 karolherbst: wtvr
15:22 nyef: ... damned blob driver. "Error: Driver 'nvidia' is already registered, aborting..." /-:
15:25 imirkin_: skeggsb: should i be worried that i see no references to DRM_FORMAT_* in dispnv04?
15:25 imirkin_: (other than the overlay stuff)
15:26 skeggsb: i suspect it's still using the legacy method
15:26 skeggsb: depth/cpp etc
15:26 imirkin_: oh right yea
15:30 rxr: here is another bug id: https://bugs.freedesktop.org/show_bug.cgi?id=91779
15:32 imirkin_: ah right. and iirc that guy works (worked?) at apple...
15:33 rxr: I'm more intersted to have a working display than the job of other reporters, ... :-/
15:33 imirkin_: you can ignore the things i say - i won't mind.
15:34 rxr: is it so hard to move the bios scan before destroying the temporary efi fb?
15:34 imirkin_: should definitely be achievable
15:34 rxr: at least I would have some text typing ability, ...
15:34 imirkin_: would require some restructuring though i think
15:35 skeggsb: hmm, that sounds like a reasonable request.. we do that only for chipset so far
15:35 skeggsb:adds a todo
15:35 rxr: that has already a bug id, too:
15:35 rxr: https://bugs.freedesktop.org/show_bug.cgi?id=91804
15:36 skeggsb: rxr: ack, thanks!
15:36 rxr: and I wanted to debug the optical spdif in :-/ now I spend the whole afternnon on getting video :-/
15:38 imirkin_: rxr: just do a regular boot... what do you need efi for?
15:39 rxr: I phased out non efi boot media some years ago ;-)
15:39 imirkin_: and now you are suffering the consequences...
15:39 skeggsb: or, if you do need efi, do a legacy boot, save the image, and point nouveau at it from the filesystem
15:41 rxr: yeah, I try to find some old usb stick for that
15:41 skeggsb: if it weren't apple, there'd be good reason to sink time into it... but, yeah :)
15:42 pmoreau: karolherbst: Almost left without getting your trace… --"
15:42 rxr: well given there are million of identical machines out there maybe it would be worth if this machines would with recent linux distirbutions when people want to change to Linux ?
15:43 rxr: this shoudl work with 4.10.10 nouveau: config=NvBios=vbios.rom ?
15:43 ccaione: imirkin_: by any chance did you have time to look at https://bugs.freedesktop.org/show_bug.cgi?id=100446 ?
15:43 imirkin_: nope, sorry
15:43 ccaione: np
15:57 jamm: hakzsam, imirkin: my initial attempt at sched codes: https://hastebin.com/ociculequt.bash
15:58 jamm: i'm still doubtful on some of the stall counts and barriers i set.. would really appreciate your feedback :)
15:59 jamm: i avoided doing sched codes for the rest as they're mostly similar with the exception of a couple of them
15:59 jamm: rest of the shaders*
15:59 imirkin_: does it work? :)
15:59 hakzsam: jamm: nice, I will have a look later today
15:59 jamm: imirkin_: i'll give it a try!
16:00 dboyan: well, I haven't learned how to calculate sched code for maxwell yet
16:01 dboyan: much more difficult from the look
16:01 jamm: dboyan: that's true.. i think i've barely scratched the surface here
16:01 jamm: and i'm sure i've messed up in some of the stall counts
16:02 jamm: hakzsam: cheers :)
16:02 jamm: imirkin_: will have to install envyas and check, will install that now
16:13 dboyan: Once I dreamed about having an automatic "sched code calculator" that can insert the correct sched codes given the instruction sequences
16:13 dboyan: There won't be a lot of people using it though.
16:14 dboyan: But manually calculating, or more othen than not, guessing is really painstaking when writing them
16:14 karolherbst: pro tip: have a standalone compiler
16:15 karolherbst: 1. extract codegen to seperate project 2. port envyas to use it as a compiler backend
16:15 karolherbst: 3. profit
16:16 dboyan: rofl ;)
16:16 karolherbst: I am actually serious
16:17 dboyan: yeah, that would be *really* nice
16:18 rxr: err
16:18 rxr: I now loaded nouveau with config=NvBios=mb31.vbios
16:18 rxr: I get:
16:18 rxr: [ 192.677587] nouveau 0000:01:00.0: NVIDIA G84 (084700a2)
16:18 rxr: [ 192.678126] nouveau 0000:01:00.0: bios: version 60.84.49.03.00
16:18 rxr: [ 192.678889] nouveau 0000:01:00.0: devinit: 0xb051[ ]: unknown opcode 0x00
16:18 rxr: [ 192.678896] nouveau 0000:01:00.0: preinit failed with -22
16:18 rxr: [ 192.678898] nouveau: DRM:00000000:00000080: init failed with -22
16:18 rxr: [ 192.679650] nouveau: probe of 0000:01:00.0 failed with error -22
16:18 karolherbst: rxr: did you check that your vbios file is valid?
16:19 rxr: nope
16:19 rxr: I booted some old crap CD and copied it from /sys/device/pci/.../rom
16:19 rxr: # file mb31.vbios
16:19 rxr: mb31.vbios: BIOS (ia32) ROM Ext. IBM comp. Video (94*512)
16:19 karolherbst: don't do that
16:19 karolherbst: it hardly ever works
16:20 rxr: it was from some wiki page !!!
16:20 rxr: https://nouveau.freedesktop.org/wiki/DumpingVideoBios/
16:20 karolherbst: wiki pages are usually out of date
16:20 imirkin_: you need the vbios for your board.
16:20 karolherbst: I will fix that page
16:20 rxr: what shoudl I do then ??? !!!!
16:20 imirkin_: you need to load nouveau with a non-efi boot
16:20 imirkin_: and copy the vbios from /sys/kernel/debug/dri/0/vbios.rom
16:20 karolherbst: the last method is the best
16:21 rxr: oehm, ...
16:21 karolherbst: I will edit that page now
16:21 rxr: it's a bit unhandy to get the vbios like that
16:22 jamm: karolherbst: i was thinking the same, it would probably benefit to get the correct stall counts as much as possible algorithmically
16:22 imirkin_: ok, well the alternative is to do an acpidump and extract it by hand
16:22 imirkin_: which imho is decidedly more unhandy
16:22 karolherbst: done
16:22 imirkin_: and that's if it's even in the acpidump - might not be, could be just a reference to some system memory accessed by the acpi engine.
16:23 rxr: imirkin_: if you tell me what I should apidump exactly, ...
16:23 jamm: but is it justified, given that we mostly have 4-5 of the shaders using pretty much the same asm except for the variables/registers?
16:23 karolherbst: rxr: boot in bios mode and extract it via debugfs
16:23 karolherbst: seriously
16:23 imirkin_: rxr: i've only ever done it that way once. extremely manual process. just let nouveau do its thing.
16:24 imirkin_: and then copy its work
16:31 rxr: has anyone an idea how to scan the system memory on an EFI boot if the tables are somewhere?
16:33 jamm: imirkin_: envyas installed, make ran. How do I test NV110FP_Composite_A8? It's probably used in a ton of places i assume..
16:35 karolherbst: jamm: most likely part of the make files somewhere
16:35 karolherbst: just try to compile and see if anything changed?
16:37 jamm: karolherbst: yeah, just did. and looks like i can see the glitches of my evildoing already XD
16:37 karolherbst: nice
16:38 jamm: the shadows GNOME windows look like they have artifacts
16:38 jamm: shadows behind*
16:42 jamm: well, even though it's bad output, i'm really glad to see some output of the sched code changes, Just got some more motivation :D
16:43 jamm: will debug more into this tomorrow
16:44 jamm: my first task would probably be to understand the exa operations these shaders correspond to, and where they're used so i can get an idea of which shaders i'm looking at
17:13 pmoreau: karolherbst: https://phabricator.pmoreau.org/F129401 I’ll send it to the dumps later
17:55 pmoreau: RSpliet: With my various changes to lengths, it no longer complains, but neither does it reclock :-/
17:56 karolherbst: does this make sense? https://gist.github.com/karolherbst/08def814730f885c17fc948875cab86c
17:57 karolherbst: it's funny that for memclk it is always like this: a a a*4
17:57 karolherbst: ...
17:57 karolherbst: a*4 a*4 a
17:59 pmoreau: karolherbst: Not sure whether you checked the logs, but I posted a link to the trace. :-)
17:59 karolherbst: k
17:59 pmoreau: I’ll send it shortly to the dump list
17:59 karolherbst: could you upload it to git instead?
17:59 pmoreau: Same as the VBIOS repo?
18:00 karolherbst: yeah
18:00 karolherbst: there are all our traces as well
18:00 pmoreau: I need to fire up my old laptop then, since it is the only one with access to the repo.
18:01 karolherbst: same table on gp107: https://gist.github.com/karolherbst/482ba7f7431e58461ebdbeb9eb2282ea
18:01 karolherbst: it looks too right to be wrong, doesn't it?
18:01 karolherbst: except unk0 is odd
18:01 karolherbst: but meh
18:04 Lyude: karolherbst: I noticed you added reclocking for pascal to trello o-o
18:04 karolherbst: Lyude: !
18:04 karolherbst: well, somebody has to do that
18:04 karolherbst: :p
18:05 Lyude: ah, was hoping we got PMU firmware or something nice like that
18:05 karolherbst: mhhh, well, we don't need the firmware to do the reclocking
18:05 karolherbst: just for controlling the fans
18:05 Lyude: ah
18:05 Lyude: Oh, that's a lot better then I thought
18:05 karolherbst: anyway, it sounds better if we can say: "well, we implemented reclocking for pascal, but because of nvidia we can't control the fans" :p
18:06 karolherbst: Lyude: same for Maxwell2
18:06 Lyude: yeah, thank nvidia for your GPU overheating
18:06 karolherbst: we can already reclock Maxwell2
18:06 karolherbst: just the fan keeps spinning too slow
18:06 Lyude: karolherbst: I would love to help out with that btw
18:06 karolherbst: well, it's just AES in hardware, go ahead and figure something out :p
18:07 Lyude: sorry, I meant the reclocking part
18:07 karolherbst: mhh, but there is something nice you can do
18:07 karolherbst: ohhh :(
18:07 Lyude: if I could help out with the fans though I'm down for that too, but it doesn't sound like that's possible atm
18:07 karolherbst: you would get more fame if you solve our little hardware crypto problem though :D
18:08 karolherbst: and free beers whenever we meet from me :p
18:08 Lyude: hehe, it's always possible.
18:09 Lyude: lemme know what I can do with the pascal reclocking as well though
18:09 karolherbst: mmiotraces
18:10 Lyude: gotcha, what do you need those run on?
18:10 karolherbst: ohhh I have an idea
18:10 karolherbst: no idea how this works again, but maybe we figure something out
18:10 karolherbst: mupuf wrote a tool to fake the load on the gpu
18:11 karolherbst: with that you can get it to upclock in tiny little steps
18:11 karolherbst: https://github.com/mupuf/pdaemon_trace
18:11 karolherbst: and this patch: https://gist.github.com/karolherbst/acba9ce69fe4b61838de5cb9fe5df2fc
18:12 karolherbst: you basically need to run make inside the nouveau folder
18:12 karolherbst: ohhh wait
18:12 karolherbst: much simplier
18:12 karolherbst: you only need to compile pwr_read/ppwr_counters_fake.c
18:12 karolherbst: with the patch applied
18:14 karolherbst: and build it somewhat like this: gcc ppwr_counters_fake.c -L /home/karol/Dokumente/repos/envytools/build/nva/ -L /home/karol/Dokumente/repos/envytools/build/nvhw -lnva -lpciaccess -lnvhw
18:17 karolherbst: and then running "sudo ./ppwr_counters_fake 3 10" should give you 10% GPU utilization inside nvidia-settings
18:18 karolherbst: running it like "sudo ./ppwr_counters_fake 3 61" makes nvidia clock in little steps for me -> 233, 244, 248, 257, 284, 293....
18:18 karolherbst: and then a trace of that would be perfect
18:19 karolherbst: you need to somehow figure out which load is the sweet spot so it starts to reclock
18:20 Lyude: karolherbst: alright, once I get these opengl extensions done I'll probably start looking at that
18:20 karolherbst: awesome, thanks :)
18:20 karolherbst: here is the table of the PMU counters for various chipsets: https://gist.github.com/karolherbst/1eb3759be936406734bcfa308c2652b2
18:20 karolherbst: pascal should be like maxwell2 basically, but I have no idea
18:21 karolherbst: so "3" is a guess
18:21 karolherbst: could be something else
18:26 Lyude: btw karolherbst I might also give another try at getting the PMU firmware from the blob, to hopefully save myself the trouble of setting up a different cooling system
18:27 karolherbst: :)
18:29 imirkin_: Lyude: any luck testing dboyan_'s finding about viewport outputs?
18:29 Lyude: imirkin_: just started working on that again
18:29 imirkin_: oh cool
19:14 pmoreau: RSpliet: The trace with the modified VBIOS was not for the GF100, but for the GF107/GF108 (I don’t remember between the two, but I know which card it is), right?
19:26 RSpliet: pmoreau: yes I believe so
19:27 pmoreau: Ok Will try to get it tonight then
19:29 RSpliet: thanks
19:33 pmoreau: karolherbst: Pushed
19:34 hakzsam: jamm: you are missing a wait-dep-bar on mufu
19:35 hakzsam: jamm: also, fmul doesn't need any barriers
19:35 hakzsam: so you can remove the two 'wt' after the fmul
19:36 karolherbst: pmoreau: thanks
19:36 hakzsam: jamm: once you have an updated version, show me again. I only looked at it quickly
20:00 imirkin_: pmoreau: there's no GF107
20:00 imirkin_: only a GF108
20:00 imirkin_: there's a GK107...
20:00 pmoreau: Yeah, I just saw that on the wiki
20:01 pmoreau: And, by looking around, I can’t seem to find a GF108. But I do have a GF114.
20:01 imirkin_: i have one... they're the cheapo ones
20:01 pmoreau: Not sure how I ended up confusing GF108 and GF114… o.O
20:02 pmoreau: Or maybe I also have a GF108, it is just well hidden
20:02 RSpliet: in the vbios repo you only have an nvce
20:03 pmoreau: Ah, I was going to check. Thanks
20:03 pmoreau: On the other hand, I doubt I uploaded the VBIOS of all the cards I have. :-(
20:03 pmoreau: Anyway, let’s get the trace for the GF114 then.
21:04 nyef: ... Over four panels, three of which work with HDMI audio, one of which does not, I see nothing plausible in the ELDs in terms of differences.
21:04 nyef: I have yet to manage to get the blob to run on this hardware.
21:04 imirkin_: nyef: different frequency requirements?
21:06 nyef: Two of the panels have ELDs which differ in monitor name, manufacture id, product id, and sad0_bits. The "good" one supports 16 20 24, while the "bad" one supports "16 24".
21:06 nyef: But one of the other "good" ones only supports 16 there.
21:06 imirkin_: which hw is this?
21:07 imirkin_: (i mean gpu-side)
21:07 nyef: gt215.
21:07 imirkin_: hm ok. weird.
21:07 imirkin_: g84 i kinda expect to be broken
21:07 nyef: Which is mcp89, which supposedly has special support in the HDA driver.
21:07 imirkin_: i hadn't heard of issues with gt215
21:08 imirkin_: hmmmm
21:08 nyef: Yes you have: We had one other report in here a few weeks back.
21:08 imirkin_: right - mcp89.
21:10 imirkin_: did it work before? :)
21:10 imirkin_: [your changes, that is]
21:11 nyef: No. My changes for hdagt215 got it working with three of these panels, but not the fourth.
21:11 imirkin_: i meant before your 3d changes
21:11 imirkin_: which, among other things, started sending real infoframes down
21:12 nyef: Look again: The g84 and gt215 patches specifically *don't* alter the audio infoframe, and it seems that gk104 and gf119 don't have audio infoframe registers anymore.
21:12 imirkin_: ok
21:13 imirkin_: i'm mostly going from memory
21:13 nyef: Hrm.
21:13 nyef: MCP89 HDMI uses patch_nvhdmi, not patch_nvhdmi_8ch_7x.
21:17 imirkin_: i suspect that's right... mcp89 uses gt215 disp, while mcp77 uses g84/g94-style disp
21:18 nyef: There's also some tegra magic in there as well, which gets picked up by the tegra drm driver to propagate to the infoframe manually.
21:34 nyef: I'm sortof wondering if I can hack one of my panels to add some way to display the raw infoframe data.
21:35 imirkin_: without spending $100k for a hdmi protocol analyzer? :)
21:36 nyef: $500 for a cheap hdmi protocol analyzer, but yeah.
21:38 nyef: Current problems I have with MCP89 / gt215 are this audio thing, and some (DPort only?) HPD thing.
21:41 nyef: So, patch_hdmi.c containing special code to set the infoframes on "older" nvidia hardware and not on "newer" nvidia hardware likely corresponds to the removal of the audio infoframe registers... on gf119 and gk104.
21:42 nyef: But gt215 still has audio infoframe registers, as does g84.
21:42 Lyude: imirkin_: btw, "2017-04-15 10:20:56 imirkin that thing where it stores the viewport off should only happen for geometry shaders" are you talking about the part in that block that says "Save the viewport index into a scratch register so that it can be exported at EMIT time"
21:42 imirkin_: Lyude: yes. that needs to be only hit for geometry shaders
21:42 imirkin_: not for != fragment shaders.
21:43 Lyude: ah, gotcha, and then the issue is we skip the mkStore for the whole thing if it's a fragment shader
21:43 imirkin_: i don't have the code in front of me
21:43 Lyude: ah, right, sec
21:43 imirkin_: however EMIT is a geometry-only thing
21:43 imirkin_: basically a bunch of applications ignore the spec
21:43 imirkin_: so we have to deal with their bullshit
21:43 Lyude: ah, well that answers my question anyway but https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp#n2156
21:44 imirkin_: i.e. they want to do like gl_ViewportIndex = foo; Emit(); Emit(); Emit();
21:44 imirkin_: this is not legal in GL, and the nvidia hw doesn't work that way.
21:44 imirkin_: so we fake it
21:44 imirkin_: we rewrite that to be t = foo; gl_ViewportIndex = t; Emit(); gl_ViewportIndex = t; Emit(); etc
21:44 imirkin_: [also for layer iirc]
21:46 nyef:far prefers projects where if someone violates the spec, and their code breaks, we get to point to the spec and say "here's where you screwed up, fix it."
21:46 Lyude: hehe
21:47 imirkin_: nyef: iirc the thing violating the spec is the conformance suite :)
21:47 nyef: SBCL still, a couple of years after the change was made, gets bug reports about how quasiquote behaves. And the answer always is "you're doing unportable things, and we don't care that some book recommends them, stop it".
21:47 imirkin_: but don't be mistaken about GL - the thing on the paper is basically irrelevant
21:47 imirkin_: whatever the nvidia driver happens to do is the spec
21:48 imirkin_: the thing on paper will be adjusted until it matches
21:48 RSpliet: and AMD hardware accordingly?
21:48 imirkin_: nope
21:48 imirkin_: if AMD driver does it differently, then it's buggy
21:48 imirkin_: if NVIDIA driver does it differently, then everyone else is buggy
21:49 RSpliet: yeah, so if AMD hardware does something different from NVIDIA hw, AMD hardware will be altered accordingly
21:49 imirkin_: well, i mostly mean driver-level differences
21:50 Plagman: imirkin_: that's a little bit of an exageration, isn't it? :P
21:50 imirkin_: but yeah, the driver will generally work around the hw differences
21:50 imirkin_: Plagman: a little, but not THAT much
21:50 Plagman: khronos is different now than it was 10 years ago
21:50 Plagman: way more isv-centric now
21:50 imirkin_: well i'm not privvy to the conversations that happen inside khr
21:51 Plagman: yeah
21:52 imirkin_: but the question is always "well, what does the nvidia driver do"
21:52 Plagman: i guess i'm saying in other words that what you're describing probably doesn't happen as much if it annoys isvs
21:52 imirkin_: in case of any ambiguity
21:52 imirkin_: what's ISV again?
21:52 imirkin_: is that driver makers? or application makers?
21:53 Plagman: in that context app makers and platform holders
21:53 imirkin_: gotcha
21:53 Plagman: in practice the nvidia driver is usually pretty pragmatic about not annoying isvs, so what you describe might still happen, but hopefully for good reasons
21:54 Plagman: i might be biased but being isv-driven makes for a better api overall, since they're the consumers
21:54 imirkin_: well, it mostly happens in the context of a newcomer (e.g. mesa) implementing the spec as written
21:54 imirkin_: and then applications not working
21:54 imirkin_: and then the spec being fixed to be whatever nvidia does :)
21:55 RSpliet: I do admit I'm curious how many hours has been spent behind closed doors at Khronos just cursing how mesa uncovers spec vs. implementation differences
21:56 RSpliet: is Mesa perceived as the enfant terrible, or the conformance-suite-nextgen? :-P
21:56 imirkin_: well, mesa is hardly a posterchild for perfection
22:03 imirkin_: Lyude: i've sufficiently answered your questions right? (wasn't sure if there was anything else)
22:04 Lyude: imirkin_: yep! just futzing around trying to get my vim autocomplete stuff to work with C++ in mesa
22:04 imirkin_: good luck :)
22:04 imirkin_: feel free to make a .editorconfig file if you like
22:05 imirkin_: note that i use emacs and .dir-locals.el files
22:05 imirkin_: so don't delete those :)
22:05 Lyude: Unfortunately this isn't a thing I could stick in editorconfig, the completion thing I use (YouCompleteMe) relies on llvm so the configuration file for it is basically telling it what flags and stuff to compile things with
22:05 imirkin_: oh dear
22:05 imirkin_: i prefer the emacs word-based completion thing
22:05 Lyude: yeah. they've got scripts to automate a lot of it so you only have to make a few changes
22:06 imirkin_: alt-/ -- just press that, and it searches back in your buffer and other open buffers for tokens that start with the current string
22:06 imirkin_: covers like 99% of cases :)
22:06 Lyude: ah, i've got that in vim too but it's nice having something that's context aware
22:06 imirkin_: the eclipse generation...
22:09 Lyude: hehe]
22:20 RSpliet:hides
22:20 nyef: "Why does the IDE think that this file defines more than a hundred functions all called DEFOP()?"
22:21 hakzsam: Lyude: youcompleteme?
22:21 Lyude: hakzsam: yeah, it's an autocompletion engine for vim. For C and C++ it can hook into llvm and use that for completion/displaying compilation errors
22:21 hakzsam: Lyude: exactly, and it works very nice with c++
23:18 PyroSamurai: hey so I need OpenCL to work on the FW/Drivers for a program I working on so I've come to help implement it. Luckily for me it appears on the newbie ToDo list so it looks like I can be of use.
23:20 RSpliet: PyroSamurai: that todo item should be labelled "hard"
23:21 RSpliet: we have someone making small steps towards OpenCL support - mainly on the compiler side
23:21 RSpliet: if you're interested in helping, check back with pmoreau tomorrow CEST
23:22 PyroSamurai: https://github.com/pathscale/pscnv/wiki/TODO-for-newcomers Well it is there and regardless of its difficulty level, I plan to make a go at it or my program will be useless on a libre operating system. So yeah I'll come back tomorrow then :)
23:23 RSpliet: Don't expect it to be a regular walk in the park though... more like a walk in the park when you just got a new artificial hip and two prosthetic legs
23:23 RSpliet: heh, that is a todo page last edited 6 years ago mind you
23:23 PyroSamurai: the entire site is fairly badly update ;p
23:24 RSpliet: on a project (pscnv) that appears to be abandoned and certainly not worked on by any nouveau developers
23:24 RSpliet: we keep a more accurate todo list on https://trello.com/b/ZudRDiTL/nouveau - but that does not include bigger projects like OpenCL
23:25 PyroSamurai: well, openCL is still easier that CUDA compute or whatever because it isn't a proprietary standard, but yeah, I expect it to be hard but I also expect it to be very useful once implemented
23:25 PyroSamurai: than*
23:25 RSpliet: definitely true!
23:26 RSpliet: and we could use some more hands on the project :-) How is your experience with (non-LLVM) compilers?
23:28 PyroSamurai: Minimal, but I've spent quite a few years in software RE realm if that helps. I know C and C++, python, and many web languages (which are really relevant here)
23:28 PyroSamurai: arent*
23:29 PyroSamurai: I always mess up on the contractions ;3
23:29 PyroSamurai: ASMx86 as well if that helps
23:30 imirkin: PyroSamurai: welcome :)
23:30 PyroSamurai: imirkin: thanks :)
23:30 imirkin: you should sync up with pmoreau regarding opencl - he's been working on making spir-v work
23:31 imirkin: [and using the opencl -> spirv compiler to generate the spirv]
23:40 PyroSamurai: okay, I'll look into spir-v as prep for talking to him tomorrow. I'm still very noob on hardware-interacting software so I have much to learn. I wish the openCL info on amd's sites didn't always read as a sales pitch and actually explain things better.
23:41 imirkin: well, spir-v is purely a "software" concept
23:41 imirkin: it's a bytecode spec for compute shaders
23:42 imirkin: er, well, for all shaders. including compute.
23:42 PyroSamurai: I meant firmware/drivers/kernels in general.
23:42 imirkin: vulkan uses it heavily, and it's also possible to use it in opencl
23:42 imirkin: (and to compile opencl c -> spirv)
23:43 airlied: if only they'd get the spir-v code into llvm properly
23:44 imirkin: i have hope that that will happen at some point
23:44 imirkin: call me young and naive if you must :)
23:44 imirkin: although the fact that they didn't for SPIR iirc is somewhat worrying, esp since SPIR's definition was "llvm ir"
23:45 PyroSamurai: If you are young and naive, well I must be a toddler lol
23:45 airlied: imirkin: well for SPIR that would have been harder, since LLVM IR would have diverged
23:46 imirkin: not sure who thought that was a good idea tbh
23:46 airlied: but it would be nice to have CUDA->SPIRV as well
23:46 imirkin: (using llvm ir bytecode for the "spec")
23:48 airlied: imirkin: yeah clearly not a sane individual
23:56 nyef: Oh, *nuisance*. I can smack around the audio infoframe, even disable it, and it doesn't kill HDMI audio on the dport.
23:57 nyef: I may have to give up on this one at this point. /-:
23:59 skeggsb: iiuc the hw can/will generally create/overwrite bits of the infoframes itself