00:47 chatter29: hey guys
00:48 chatter29: allah is doing
00:48 chatter29: sun is not doing allah is doing
00:48 chatter29: to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
02:01 Manoa: hi, I would like to know if there has been much progress with GK110B, it looks like im stucked with it because I fried my radeon card :x, the last time I checked my linux was a year ago, I heard this card the last unfirmwared card, if the driver is good im thinking to do some winenine checking to see if and how the games work on this slackware
02:04 Manoa: this should work nicely along with the new mesa improvements
02:05 Manoa: my card is not standard, the last time I tried to get nouveau to work with a classified card was with a fermi and it was stucked at boot clocks and there was nothing to do about it :x
02:06 nyef: What's your opportunity cost for just trying it?
02:18 Manoa: well, build new kernel, build mesa+drm, I suppose that's all
02:21 Manoa: and yes build winenine too
02:48 imirkin: Manoa: with kernel 4.10, you should be able to reclock your GK110B
02:49 imirkin: Manoa: all post-nv40 gpus require firmware. starting with gm20x, that firmware has to be cryptographically signed by nvidia.
03:16 Manoa: ok, thank :)
03:36 mooch: imirkin, is there any way to dig out the key so we can... sign our own firmware?
03:39 imirkin: not without a camera and some acid
03:39 nyef: Sounds like something to do with an already-dead card.
03:40 nyef: ... wasn't there an old video game called "decap attack"?
03:41 nyef: Heh. There was. On the SEGA Genesis.
03:43 mooch: well shit
03:43 mooch: i think we should get all GM200+ gpus decapped then
03:45 nyef: Questions that come to mind include "how do we go from a good set of die shots to having the signing key" and "did they find a way to protect against this style of hack anyway?"
03:46 imirkin: "not easily"
03:47 nyef: And there's also the extreme plausibility that it would just get the validation key, and we'd still need to get the signing key from there, the difficulty of which is pretty much the basis of PKI.
03:47 imirkin: i don't think we know the specific scheme... maybe we do, dunno
03:47 imirkin: (i don't)
03:49 nyef: Yeah, I'm certainly not claiming that we know which scheme it is, or even that it *is* a two-key system, even though not using a two-key system would be basically stupid.
03:49 nyef: I guess on one level, they don't need to be too-too worried about someone getting the validation key if it's still computationally infeasible to reverse it to get the signing key in less than, say, a decade.
03:50 nyef: And even then, they may be generating new keys for every major hardware rev or something obnoxious like that.
03:55 mooch: still tho, requiring signed firmware basically makes emulating these cards impossible for the time being
03:55 mooch: then again, who the hell would want to emulate a gtx 950 or some shit on a current computer?
03:55 nyef: Yes-and-no. It makes the reverse engineering difficult-to-impossible, but you can "just" have it ignore the firmware signature.
03:56 mooch: is signing something the same as encrypting it, or no
03:56 mooch: ?
03:57 imirkin: in your emulation, you could just not worry about cehcking the signature :)
03:57 nyef: Typically not. A "signed" message is sent in plaintext, but with an attached certificate that says "this is a ``digest'' of the message text, encrypted with a key." And to verify the signature you decrypt the digest and compare it to a digest of the received message text.
03:58 mooch: ah
03:58 mooch: imirkin, how would we reverse engineer the firmware tho?
03:58 imirkin: huh?
03:58 nyef: Heh. Didn't I ask this a while ago?
03:58 mooch: the firmware and how it works needs to be REd to run it
03:59 imirkin: it's just a cpu...
03:59 imirkin: falcon isa
03:59 imirkin: nothing special
03:59 imirkin: you can read the firmware, no problem...
04:00 mooch: oh
04:00 mooch: well then
04:01 mooch: i wonder what nv40 firmware is like
04:02 imirkin: the ctxprogs...
04:02 imirkin: i think they're only partly understood
04:02 mooch: oh
04:02 mooch: shir
04:02 mooch: *shit
04:03 Manoa: ilia I've read your posts on phoronix, you very well explained the problems with achieveing performance parity with nv drivers :)
04:04 imirkin: the problem being that it's difficult? :)
04:04 nyef: ... starting with one of the reasons that the nv drivers have such good performance is that they're sloppy on the details?
04:05 nyef: (-:
04:05 Manoa: lel xD
04:05 imirkin: be that as it may, i suspect that's not the majority of it
04:05 nyef: Yeah, probably isn't.
04:05 imirkin: (a) better compiler and (b) better buffer management
04:18 Manoa: well, I have no problem with a performance problem as long as it's not too big, and besides nv could be cutting corners that affect graphics quality to achieve this high performance
04:19 Manoa: they do it in windows, replacing game shaders with their own versions to increase performance
07:22 kotten_: Hello' I am sorry if I am wrong here but.. I have issues with my nouveau drivers and gtx 970 with my kernel ~4.8 ~4.10 (same symptoms)
07:22 kotten_: In my journalctl and dmesg is filled with these types of errors: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 []
07:23 kotten_: Is this a known issue?
07:27 gnarface: kotten_: i don't know for sure, but i think some or all of the 900 series is not supported yet, due to signed firmware requirements or something like that
07:28 gnarface: kotten_: (you might just be missing the firmware though)
07:29 kotten_: gnarface lsmod | grep -i nouveau shows me the module seem to be loaded
07:29 kotten_: I am not sure if there is something else about the firmware
07:30 gnarface: kotten_: well is it just the errors, or does opengl not work?
07:30 kotten_: I am downloading a benchmark now to see
07:30 kotten_: ure if there is something else about the firmware
07:30 kotten_: * phoenixz har avslutat (Remote host closed the connection)
07:31 kotten_: gnarface
07:32 gnarface: kotten_: sorry, i don't know anything about it that's not on here: https://nouveau.freedesktop.org/wiki/FeatureMatrix/
07:33 gnarface: i think none of the 900's and later worked, and then someone got some of them working a little
07:34 kotten_: gnarface glmark2 2014.03 seems to be running fine. So I guess it works (However I am unable to determine if it is something that the 'CPU' can handle --- yes that is how little I know about graphics)
07:36 gnarface: kotten_: oh, sorry i'm not familiar with glmark2 either. i know that if you're getting less than about 10,000fps out of glxgears on that card, un-vsynced, it probably IS falling back to CPU/software rendering
07:36 gnarface: kotten_: (cause on my old 560Ti with the proprietary drivers, i get ~30,000)
07:39 kotten_: gnarface I get 60.000 ~(My screen is 60 hz so might be because of that)
07:39 kotten_: 59.998 - 60.003
07:41 gnarface: kotten_: yea, run it like this: __GL_SYNC_TO_VBLANK=0 glxgears
07:41 gnarface: kotten_: oh wait sorry, that env variable only works for the proprietary drivers
07:41 gnarface: kotten_: i forget what the nouveau equivalent is, something like "sync_vblank=0" i think
07:41 kotten_: gnarface you don't need to be sorry I am really greatful you are so helpfull minding me being so stupid :)
07:42 kotten_: sync_vblank=0 just a bash enviroment variable will work?
07:42 Manoa: vblank_mode=0 glxgears
07:43 kotten_: [root@localhost firmware]# sync_vblank=0 glxgears
07:43 kotten_: Running synchronized to the vertical refresh. The framerate should be
07:43 kotten_: approximately the same as the monitor refresh rate.
07:43 gnarface: kotten_: yea, just an environment variable. should work for everything if you set it globally, but beware that things like desktop compositing can impose their own vsync mechanisms separately
07:43 kotten_: :\
07:43 gnarface: kotten_: i got it wrong, Manoa has the right one. it's vblank_mode=0
07:43 kotten_: running that now
07:44 kotten_: This seems to work . I get 9700 - 9890
07:44 gnarface: ok
07:44 gnarface: unfortunately too low to know for sure if it's being hardware accelerated though
07:44 gnarface: that looks low enough a modern cpu could be doing that in software
07:45 gnarface: kotten_: try running this: glxinfo |grep direct.render -i
07:45 kotten_: gnarface yes I have a 6700k
07:46 kotten_: Direct rendering: Yes
07:46 gnarface: hmm
07:46 gnarface: glxinfo says you're hardware accelerated
07:46 gnarface: maybe that's just the best nouveau can do with that card right now :-/
07:46 gnarface: i wish i knew more, that's all i got
07:46 gnarface: the nouveau driver is missing critical features across the board for many things besides just the hardware accelerated 3d part.
07:47 gnarface: (inability to change the gpu clock speed on the fly the way the proprietary drivers do, for one)
07:47 kotten_: gnarface ok. Thanks for your time.
07:47 kotten_: gnarface hmm
07:47 kotten_: Could be some BIOS setting perhaps that allows clocking/autoclocking or something that could mess it up?
07:47 gnarface: kotten_: i think this channel is more active in the daytime on US business hours
07:48 gnarface: kotten_: no, i don't think this is something you can sabotage with motherboard bios settings
07:48 gnarface: the problem is most likely in mesa, or nouveau itself
07:48 gnarface: and most likely related to that closed firmware crap
07:49 gnarface: kotten_: smarter people than me hang out here in the day time though, they very well might have performance tips to help you, or at least some further tests you can run
07:49 kotten_: gnarface yeah. I should not have bought such a high end GPU in retrospect
07:50 kotten_: gnarface well you sure seem to know alot. So thanks for your time
07:50 gnarface: you are welcome
07:50 gnarface: nobody is making good video cards for open source drivers yet
07:50 kotten_: I guess there aren't any 100% open source(open firmware) gpu's thaty could be
07:50 kotten_: yeah
07:51 gnarface: AMD is trying hard, but they've got a couple years to go before they have a chance of regaining ATI's 90's era glory
07:51 gnarface: intel's drivers ironically are great now
07:51 gnarface: but all their cards are just pathetic
07:52 kotten_: gnarface does intel have gpus?
07:52 gnarface: yea, but most of them are shipped integrated
07:52 gnarface: they don't have a lot in the way of stand-alone devices
07:53 gnarface: for gaming in linux, it's pretty much a choice between AMD and Nvidia hardware right now
07:53 kotten_: aha. well last time around I reserved my GPU for qemu/KVM and ran windows for gaming. But now since alot of games I am playing I tought about going 100% linux
07:53 kotten_: *alot of games are coming to linux
07:53 gnarface: i know it's great :)
07:53 kotten_: However if I start gaming I guess I will need to use properitary drivers anyway :\
07:54 gnarface: remember when the only commercial game we had was some iD software guy's after-hours basement svgalib port of quake1?
07:54 kotten_: gnarface I am not that old :)
07:55 gnarface: some games do actually run pretty good on nouveau, but it's still the exception, not the rule. most of the big game publishers don't bother testing on open source drivers, and a couple of them don't even bother supporting non-nvidia hardware :(
07:56 gnarface: i hear wine-gallium-9 is approaching windows performance parity for directx9 stuff though :)
07:56 gnarface: (still not sure if that counts for anyone but AMD users)
07:57 gnarface: there's a ton of indie games on steam now, and lots of them (even good ones) don't have enough graphical complexity to need proprietary drivers or a fancy video card though. so that's a good trend.
07:57 gnarface:is that old
07:58 kotten_: gnarface yeah I have seen that. That is really cool that it goes back to the 'old way'
07:58 kotten_: Most fancy-pancy stuff is just for show and not really making the game much more enjoyable
08:07 Manoa: speak of fancy-pency: doom 4 suckx big time
08:07 gnarface: hah
08:07 gnarface: know what doesn't though? ioquake3
08:08 gnarface: (ok i liked quake4 DM just fine too though, TBH)
08:08 Manoa: we have open source for that kind of gaming, xonotic nexuiz
08:08 Manoa: and quake3 of corse
08:08 Manoa: you can also do doom 3
08:09 gnarface: did anyone ever finish doing a decent multiplayer mod for doom3?
08:09 gnarface: i feel like i ask that question every year and still come away finding out it's a work in progress
08:09 Manoa: it depends how you call decent
08:09 gnarface: hah
08:09 gnarface: oh, "no" then, probably
08:10 Manoa: MCS mars city security got the graphics and I added some texture mods to it makes it look realy good, but hardcore "last man standing 4" say it's not loyal to the style because some things there are missing
08:10 Manoa: MCS has proper netcode and has graphics effect from sikkmod
08:11 Manoa: added with textures this makes it the best, in my opinion only, others will not agree
08:11 Manoa: you also have opencoop mod but that one was never finished, it's broken in many places, like delta
08:11 Manoa: I tried to fix it, but found out that without programming it's not possible
08:12 Manoa: so in the end you have 2 options: MCS and LMS4
08:12 Manoa: LMS4 can be equipped with textures and parallax occlusion mapping not much more, MCS has the same but full sikkmod effects in addition
08:13 Manoa: including HDR, ambient occlusion, depth of field, bloom, blur ... etc
08:14 Manoa: but one problem: the gamex86.dll only exists for windows, there is no linux version of it :x
08:14 Manoa: this meens you must run doom 3 on wine to have all the graphics
08:15 Manoa: LMS4 POM might work, I never tested that, but POM is just one thing so
11:07 Lekensteyn: I'm seeing some use-after-free in drm_calc_vbltimestamp_from_scanoutpos with v4.10.9+KASAN, any ideas? http://sprunge.us/ZeQQ
11:07 Lekensteyn: (with 4.10.5-ARCH I ended up with two issues that look like memory corruption, hence this attempt with KASAN)
11:09 Lekensteyn: could the above be related to https://bugs.freedesktop.org/show_bug.cgi?id=100431?
11:12 karolherbst: Lekensteyn: you know the loc?
11:13 Lekensteyn: karolherbst: addr2line you mean?
11:13 karolherbst: if you want to do it complicated, yes
11:13 Lekensteyn: what is the easy method then? :P
11:13 karolherbst: gdb nouveau.ko -> p *drm_calc_vbltimestamp_from_scanoutpos+0x625
11:13 karolherbst: uhh
11:13 karolherbst: l
11:13 karolherbst: l *
11:13 karolherbst: ....
11:13 karolherbst: l *drm_calc_vbltimestamp_from_scanoutpos+0x625
11:15 Lekensteyn: (had to check vmlinux,) it points to drivers/gpu/drm/drm_irq.c:823
11:15 karolherbst: why vmlinux? is it builtin?
11:16 Lekensteyn: yes, drm is builtin in this kernel
11:16 karolherbst: ohhh, true
11:16 karolherbst: right
11:17 karolherbst: mhh
11:17 karolherbst: is crtc_htotal of size 4?
11:18 karolherbst: Lekensteyn: check nouveau_display_vblstamp+0x16d as well
11:18 karolherbst: mhhh
11:18 Lekensteyn: drivers/gpu/drm/nouveau/nouveau_display.c:175
11:18 karolherbst: and nv50_head_atomic_destroy_state+0x1d and nv50_head_atomic_duplicate_state+0x72
11:18 Lekensteyn: that is basically where nouveau_display_vblstamp returns :?
11:19 karolherbst: is there no call to something drm related at the end?
11:19 Lekensteyn: is there an existing script in ~/linux which takes this trace and symbolices it?
11:19 karolherbst: or the return value is the result of such a call
11:19 karolherbst: no clue, maybe?
11:19 karolherbst: anyway, the object was fred in "nv50_head_atomic_destroy_state+0x1d"
11:20 Lekensteyn: in meantime: nv50_head_atomic_destroy_state+0x1d -> drivers/gpu/drm/nouveau/nv50_display.c:2319
11:20 karolherbst: ohhhhhhhh
11:20 Lekensteyn: nv50_head_atomic_duplicate_state+0x72 -> drivers/gpu/drm/nouveau/nv50_display.c:2326
11:20 karolherbst: race condition while suspend/resume?
11:20 Lekensteyn: nope, this happens during normal use
11:20 karolherbst: "nouveau 0000:01:00.0: DRM: resuming console..." just right before that kasan print
11:21 karolherbst: the gpu was off for a few seconds
11:21 Lekensteyn: I noticed it occuring after opening a new konsole; while running DRI_PRIME=1 glxgears (but not instantly in either case)
11:21 karolherbst: yeah
11:21 karolherbst: sounds like a race condition
11:21 karolherbst: and most likely suspend/resume related
11:21 Lekensteyn: probably important to know is that this is an hybrid graphics setup where I am working on an external monitor connected to nvidia's DP port
11:22 karolherbst: ... i know
11:22 karolherbst: I meant GPU suspend/resume
11:22 karolherbst: not your machine
11:22 Lekensteyn: ah ok
11:22 karolherbst: I fixed one where we do memory reclocking
11:22 karolherbst: and the GPU may happen to get suspend while reclocking
11:22 Lekensteyn: is this different from runtime suspend/resume?
11:22 karolherbst: -> not good
11:22 karolherbst: Lekensteyn: it's what I meant
11:23 Lekensteyn: ok, but then that should not be applicable here
11:23 karolherbst: why not?
11:23 karolherbst: ohh wait, mhh I see
11:23 karolherbst: the object was allocated while doing some cursor ioctl thing
11:23 Lekensteyn: right, and here is an updated trace with two more BUGs: http://sprunge.us/HJAW
11:26 Lekensteyn: I see "nvkm_disp_dtor+0x540/0x540 -> drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c:247" which looks a bit suspicious
11:28 karolherbst: 4.10.9 code base?
11:28 Lekensteyn: yes
11:29 Lekensteyn: .config http://sprunge.us/cFSP
11:30 karolherbst: I have a { in line 247
11:30 Lekensteyn: corretc
11:30 karolherbst: which is fine though. Usually it's always around +-2 lines
11:30 karolherbst: and compiler opts
11:31 karolherbst: you only get reliable line data with -O0 and -fno-omit-frame-pointer
11:32 karolherbst: also entries with a "?" are kind of garbage and not reliable. They might be right or false
11:32 Lekensteyn: any other information that would help? here are some more BUGs: http://sprunge.us/jUWO (I am running this in KDE Plasma if it helps, it did not occur from a text console)
11:34 karolherbst: Lekensteyn: can you check the code after drm_atomic_helper_update_plane+0x2b3?
11:35 Lekensteyn: include/linux/kref.h:73
11:35 karolherbst: meh... :(
11:36 karolherbst: then increase the number until it makes sense
11:37 Lekensteyn: which number/
11:37 karolherbst: the offset
11:38 Lekensteyn: drm_atomic_helper_update_plane+0x2b6 -> drivers/gpu/drm/drm_atomic_helper.c:2142
11:39 karolherbst: drm_atomic_helper_disable_plane, k
11:40 karolherbst: that inlining :(
11:41 Lekensteyn: I'll add addresses and lines to everything, sec
11:41 Lekensteyn: *files+lines
12:13 Lekensteyn: karolherbst: output with lines added: http://sprunge.us/WHIa
13:35 imirkin: kotten_: did you get your issue resolved? i assume you have a GTX 970 with 4 GB of VRAM?
13:36 imirkin: kotten_: the solution, btw, is to use drm-next - that should have a fix for your issue.
13:37 gnarface: kotten_: do what this guy says^
13:41 dboyan: imirkin: I'll send v2 of my ballot series today or tomorrow with hakzsam's feedback. Do you think it's okay or I'd better wait of some additional comments?
13:42 imirkin: i think it's fine
13:42 imirkin: dboyan: btw, i think for the clock stuff, there are 2 approaches we can take
13:43 imirkin: dboyan: (a) just use clocklo and move on with life (leaving the low bits of the logical 64-bit result as 0)
13:43 imirkin: dboyan: (b) grab clockhi, clocklo, clockhi. if the second clockhi != first clockhi, repeat. i THINK that's what blob tries to do but fails at.
13:44 dboyan: (b) is exactly what I've been thinking :)
13:45 imirkin: well, (a) is what we have to do for nv50 anyways
13:46 dboyan: yeah, if we want to enable it on nv50
13:47 dboyan: i'd be fine with both, (a) is my current v2 and I think it's simpler
13:47 imirkin: i'd be happy to just go with that, and leave the more complex impl to another day
13:48 dboyan: I agree
14:26 imirkin: dboyan: can i add your s-o-b to https://patchwork.freedesktop.org/patch/148197/ ?
14:28 imirkin: actually, looks like you had it on v1, and the v2 is almost identical, so ... i'm just going to slap it on there.
14:31 kotten_: imirkin gnarface ok. I have "4GB" if i don't misrecall there was a big thing that it was not really 4 GB but 3.5
14:32 imirkin: yep
14:32 imirkin: it's actually a lot more subtle than that
14:32 imirkin: but long story short, the weird memory layout should be dealt with properly in drm-next
14:33 kotten_: imirkin okay, what is drm-next? A kernel parameter or drivers or?
14:33 imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=94990
14:33 imirkin: drm-next is a kernel tree: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
14:33 imirkin: (i guess branch is more accurate)
14:33 imirkin: which includes all the drm stuff going into the "next" kernel, 4.12 in this case.
14:36 dboyan: imirkin: okay
14:37 imirkin: dboyan: i'm trying to put together a test for nv50 shader clock. after that i'll push.
14:37 imirkin: coz the existing tests use compute shaders =/
14:37 imirkin: and ssbo's
14:38 dboyan: yeah, and requiring opengl 4.3
14:38 imirkin: that's the compute shader + ssbo bit of it :)
14:39 dboyan: well, the very 4.3 version requirement prevents it from running on my ivb
14:39 dboyan: it has compute + ssbo
14:40 imirkin: i can probably model it with 2x MRT's + texturing...
14:40 imirkin: dboyan: oh, drop the stupid 4.3 requirement then
14:40 dboyan: seems the right way
14:40 imirkin: it has to be at least GL 3.1 otherwise it won't create a core context
14:41 imirkin: this might be at the limits of shader_runner's capabilities...
15:21 karolherbst: runpm is pretty broken now :(
15:22 karolherbst: I just pluged my gamepad and runtime resume of my GPU was triggered
16:14 jamm: marcheu: https://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf is a-mazing. Thanks for all your efforts! It's helping me fill in a lot of gaps in my knowledge of graphics drivers :)
16:33 jamm: hakzsam: if i understand correctly, the "st" in the sched instruction uses "wr" for the write dependency barrier?
16:33 jamm: if that is true, what does the "wt" dependency barrier signify?
17:01 jamm: hakzsam: found it here https://github.com/envytools/envytools/blob/master/envydis/gm107.c#L45
17:03 imirkin: st = stall
17:03 imirkin: it's not an actual instruction
17:03 imirkin: it's just metadata for the shader executor
17:05 imirkin: dboyan_: shader clock series pushed. thanks!
17:07 imirkin: Lyude: any luck with the viewport thing?
17:09 imirkin: hakzsam: wanted to bring your attention to https://patchwork.freedesktop.org/patch/149240/ -- any objections?
17:10 imirkin: Satchelboi: hey, i remember a cleanup i've been dying to do everytime it ticks me off, but then totally forget. no functional change, just a bunch of string replaces.
17:11 imirkin: Satchelboi: in nouveau/codegen, there's a bunch of defines for NVISA_*, which reference a chipset.
17:11 imirkin: Satchelboi: and the chipset is passed in as part of the overall flow
17:11 karolherbst: uhhh, good idea actually
17:11 imirkin: Satchelboi: and then there are a bunch of compares against the chipset using those NVISA defines
17:12 imirkin: Satchelboi: however, chipset has nothing to do with it, and is actually confusing the matter
17:12 imirkin: Satchelboi: i'd much rather have an enum with ISA's defined - SM10, SM20, SM30, SM35, and SM50
17:12 imirkin: and use that instead of the current chipset check
17:13 karolherbst: imirkin: did you by any chance pushed/reviewed my AlgebraicOpt fixes?
17:13 Satchelboi: imirkin: I'll go in and start looking at that as soon as I finish up something else quick with karolherbst
17:14 imirkin: karolherbst: nope, totally forgot about them. pointer to your branch? or have i already pulled them in on a branch... let's see...
17:14 karolherbst: imirkin: looped_opts
17:14 karolherbst: the top commit just enables the looping, but this can wait until later
17:14 imirkin: karolherbst: wait, i pushed your patches. at least the ones i thought...
17:14 imirkin: ah. ok, yeah, i def forgot about those =]
17:14 karolherbst: postraloadpropagation, yes
17:14 imirkin: let's seeee here...
17:15 imirkin: (i hope you realize there's no malice in my forgetfulness, just busy with a ton of stuff, and don't have a good system for keeping track of the patches)
17:15 karolherbst: no worries
17:15 karolherbst: maybe we should think about a good system
17:15 karolherbst: aka PRs against your repository :p
17:16 imirkin: wellll ... that won't work too well
17:16 karolherbst: I know
17:16 imirkin: (a) i like to edit stuff and (b) mesa repo doesn't do merges
17:16 karolherbst: and patchwork doesn't recognize most of my series as merged
17:16 imirkin: can you go into patchwork and fix your name btw?
17:17 imirkin: it's lowercase, and when i download the patches, it lowercases your name as well
17:17 karolherbst: I'll try
17:21 imirkin: + if (slct->getSrc(0) != slct->getSrc(1) || slct->src(0).mod != slct->src(1).mod)
17:21 imirkin: when did that come up?
17:21 imirkin: slct can't have mods on src0/src1
17:21 karolherbst: not even neg?
17:21 karolherbst: I am sure it can have some
17:21 imirkin: not according to the target spec
17:21 karolherbst: mhh
17:22 imirkin: and not in the emission code
17:22 imirkin: src2 can have a neg
17:22 karolherbst: odd
17:22 imirkin: i'm dropping that patch
17:24 karolherbst: k, it was like months ago I wrote that anyway
17:24 imirkin: and in handleLOGOP, you check src0 == src1, but don't check their mods (which might have NOT's on them)
17:25 karolherbst: I am sure I handle that
17:25 karolherbst: let me see
17:25 imirkin: "nv50/ir: handle logops with NOT in AlgebraicOpt"
17:25 imirkin: check the src0 == src1 case
17:26 imirkin: of course a & ~a = 0, and a | ~a = 0xffffffff
17:26 imirkin: so perhaps it's a mostly-moot point
17:26 karolherbst: yeah, true. It just didn't cause any piglit test to fail afaik
17:26 karolherbst: I wouldn't merge the last commit anyway now
17:26 imirkin: that's not how the codegen code is written though :p
17:27 imirkin: it's written to handle all possible cases, not just the piglit ones
17:27 karolherbst: I know
17:27 karolherbst: I just caught that one through piglit
17:28 imirkin: sure
18:06 Lyude: hey imirkin, got a little sidetracked by work stuff for a bit but I've been working on it, unfortunately I haven't had much luck figuring out what register we're forgetting to write
18:06 Lyude: all of the supposedly unknown registers I've tried so far don't seem to have any effect
18:09 imirkin: bleh :(
18:10 imirkin: well clearly blob is doing *something* ... could be something in the shader header
18:10 imirkin: like there's a SASS_VERSION, i have nfc what it is. you could try bumping it.
18:11 Lyude: yeah, I was starting to think that it was something other then a reg as well
18:11 imirkin: unfortunately it could also be a happy combination
18:12 Lyude: A happy combination?
18:12 imirkin: well, you might have to do 2 things to get it to work
18:12 imirkin: rather than just 1
18:13 Lyude: I was thinking it might be something like that, I've been trying to combine all the reg writes I try at the same time instead of going one at a time
18:18 marcheu: jamm: glad it helps :)
18:18 imirkin: marcheu: you trailed off towards the end :)
18:19 marcheu: lazy ass!
18:30 karolherbst: :O
18:48 Satchelboi: imirkin: Can you point me out to exactly where you want the cleanup done for those strings?
18:49 imirkin: Satchelboi: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h#n78
18:49 imirkin: it'll require a bit more additional work + restructuring, but nothing excessive
18:50 Satchelboi: imirkin: Much abliged
18:50 Satchelboi: obliged*
18:51 karolherbst: we could start with checks against those magic numbers first, should be fairly easy. or did you have something else in mind imirkin?
18:52 imirkin: karolherbst: i want a ->isa in addition to chipset
18:52 karolherbst: ahh
18:52 karolherbst: okay, that has to wait until later
18:53 imirkin: ok; it's pretty minor, would take me like 10 mins to complete. probably a 1-2h job for a newcomer familiar with C.
18:55 karolherbst: Satchelboi: you should replace the lines with the constants where something like this is done: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp#n3312
18:56 karolherbst: well, that would be my idea instead of adding a field to the target class? no idea where imirkin wanted to have this, most likely though
18:57 karolherbst: Satchelboi: 0xc0 would be NVISA_GF100_CHIPSET, somebody removed that cause it wasn't used or so
18:58 imirkin: karolherbst: ok, but like fill in the ->isa field in nvc0_program/nv50_program and feed it in. ideally the chipset field would drop out entirely, although i'm not 100% sure if that's immediately practical without minor changes.
18:59 karolherbst: yeah, no idea
19:00 imirkin: i think there are some silly checks in nv50, but they can probably go.
19:00 imirkin: or just add a SM15 isa or something for the GT215+ support of prebreak & co
19:00 imirkin: (i forget exactly when it happened)
19:00 karolherbst: makes sense
19:00 Satchelboi: Just getting everything pulled up right now, sorry for the quiet
19:00 imirkin: either way, i'd like for nv50_ir to forget about chipset, just use isa.
19:01 karolherbst: yeah, good idea
19:01 karolherbst: we can do that later
19:01 imirkin: it's too confusing otherwise.
19:01 imirkin: e.g. the fact that GK20A_ISA is used for GK110, etc
19:01 karolherbst: we could name it GK110_ISA
19:01 imirkin: at least it's linear. but it didn't have to work out that way.
19:02 karolherbst: GK20A > GK110 obviously
19:02 imirkin: i'd like for all that to live in nvc0_program. and have nv50_ir just take the isa directly.
19:02 imirkin: yeah, but GK20A is 0xea whiel GK110 is 0xf0 :)
19:02 karolherbst: and name the ISA SM* something?
19:02 imirkin: yea
19:02 karolherbst: uhh, then I need to learn those SM values :D
19:03 imirkin: there's like 5. you can handle it.
19:03 karolherbst: hopefully
19:03 imirkin: i don't much care for the distinctions between SM35 and SM36 if any
19:03 karolherbst: SM36 is gk110?
19:03 imirkin: no clue. we're going to call it SM35.
19:03 imirkin: in nvdisasm: 'SM11','SM12','SM13','SM20','SM21','SM30', 'SM32','SM35','SM37','SM50','SM52','SM53','SM60','SM61','SM62'
19:04 imirkin: but we should only support a fraction of those
19:05 karolherbst: well, it might be that the changes are worth to seperate those later, but I get the feeling those things are mostly something garbage like something totally unimportant
19:05 karolherbst: like doubled threads per warps or so
19:05 imirkin: or halved
19:06 imirkin: i.e. i think SM37 is GK20A
19:06 karolherbst: k, because anything else would have made sense...
19:06 imirkin: and SM21 i think is GF110... either way, insignificant.
19:09 Satchelboi: So, to be clear before I start anything, you want me to change the Chipset constants with the equivalent SMxx value?
19:10 imirkin: yes. and fix all the chipset checks.
19:10 imirkin: to become isa checks
19:11 imirkin: RSpliet: to confirm - you wanted me to boot the GT 240 GDDR5 with your tree and see if it does. no other funny business?
19:11 karolherbst: imirkin: so first step rename those constants?
19:12 imirkin: karolherbst: sure.
19:13 imirkin: but the whole point of it is the follow-up cleanup
19:14 karolherbst: sure
19:16 karolherbst: Satchelboi: so I will reprhase that once: we want to move from chipset based checks to ISA based ones. For this we should rename the constants from being chipsets to being SM* ISAs, sm: shader model. You can either try to figure out the SM versions for gk104, gk20a and gm107 yourself with trying to find the right nvidia docs or you just ask and I will tell you
19:16 imirkin: karolherbst: can you remind me what the strap_peek thing is? is it 0x101000? or some other reg?
19:17 karolherbst: 0x101000 is right
19:17 karolherbst: funny enough, for lookup you need to check for nv10+
19:35 Satchelboi: imirkin: If I had more time I'd check the documents, but I'm pretty strapped since I need the patch out by today. Could I grab the SM version from you for now?
19:37 imirkin: Satchelboi: nv50 = SM10, nvc0 = SM20, nve0 = SM30, nvf0 = SM35, nv110 = SM50.
19:40 karolherbst: allthough we currently only have nve0, nvf0/nvea, nv110
19:40 karolherbst: nvea==nvf0 regarding the ISA
19:50 Satchelboi: imirkin: Would you prefer the names as NVISA_SMxx, or just SMxx?
19:51 imirkin: i think it makes the most sense to have a enum sm_isa { SM10, SM20, ... };
19:52 imirkin: so step 1: add the isa field to the driver info thing, step 2: convert as many chipset checks as possible to isa checks. step 3: figure out what to do with the remainder.
19:52 imirkin: i only expect you to do steps 1 and 2, not 3 :)
19:53 Satchelboi: I'm still just changing the name definitions :P I just wasnt sure what structure you preferred
20:22 RSpliet: imirkin: yeah that'll be helpful
20:23 imirkin: RSpliet: ok. i'm going to cherry-pick your series onto my local tree... should it all be fine for kepler too?
20:41 imirkin: RSpliet: gonna be trying with this friendly little monster... https://github.com/imirkin/linux/commits/tmp
20:43 RSpliet: imirkin: I verified these changes for Kepler a while ago, so should be fine
20:43 RSpliet: but I can test that myself :-)
20:43 imirkin: ok
20:44 RSpliet: Looks good. 'd be nice to push out the tail of the tree from timing names to ram pattern upload soon-ish
20:44 imirkin: hm?
20:45 RSpliet: shove it to Ben for upstreaming.
20:45 imirkin: skeggsb: btw, this really has to get resolved. please. https://github.com/imirkin/linux/commit/2e34409b626dd74de6b06d9005e36b10eba972fd
20:46 imirkin: fyi the vbios of the board having issues is now in the vbios repo, nv106/imirkin/vbios.rom.
20:48 imirkin: RSpliet: i'm going to get to the gt240 thing soonish, first want to test out the nv4x mpeg thing, and i can't plug both boards in
20:49 RSpliet: Sure, no rush
21:16 Satchelboi: imirkin: Can you throw me an example of what kind of checks would be altered by changing to Isa from chipset checking?
21:17 karolherbst: Satchelboi: I already gave you one example
21:18 Satchelboi: karolherbst: Whoops youre right, I forgot I had that tab open
21:18 karolherbst: no worries
21:55 karolherbst: imirkin: we check against chipset >= 0x84 in one case SM12 or SM13?
21:55 karolherbst: I guess 12
21:55 karolherbst: gt* should be 23
21:55 karolherbst: *13
21:56 imirkin: you can define them however you like
21:56 imirkin: i think SM10 = nv50, SM11 = nv84, SM12 = g200, SM13 = gt215
21:57 mwk: SM13 == g200, SM12 == mcp7x, gt21x
21:58 karolherbst: ui, nice: https://en.wikipedia.org/wiki/CUDA#GPUs_supported
21:58 karolherbst: the table
21:58 mwk: it'd be too simple if things went forwards.
21:59 mwk: and GT21x ISA is actually different from MCP7x as well, they added at least texgather
21:59 imirkin: and texlodquery
21:59 imirkin: and texprep
22:00 imirkin: karolherbst: however not all of those matter. the idea here is to have something useful, not to be maximally precise.
22:01 imirkin: e.g. just coz an ISA adds a new op - doesn't matter, not like an older ISA can do anything about it. so you have to trust the earlier layers not to give you crap inputs.
22:01 imirkin: so really it only matters for when the compiler would decide to do one thing vs another
22:01 imirkin: like the precont stuff (iirc)
22:01 imirkin: btw, looks like i was wrong - GK20A is SM32. wtvr.
22:03 karolherbst: imirkin: yeah well, if we have that in the code
22:03 karolherbst: in ra there is also stuff like "switch (targ->getChipset() & ~0xf) {"
22:04 karolherbst: to make things easy I assume ;)
22:04 imirkin: so keep the chipset around for now.
22:04 imirkin: the RA thing should map nicely to SM*
22:05 imirkin: basically nv50 vs nvc0.
22:06 karolherbst: well yeah, it's just a switch statement which makes things "easier"
23:18 imirkin: RSpliet: ok, i see some errors in the bios parsing: https://hastebin.com/ebepuzorom.css
23:19 imirkin: i also see some snow on the display, but i think that's "normal" for this board. i haven't really used it for display in the past.
23:20 Satchelboi: imirkin: When i finish the patches here, should I just commit them to the git? Never had to push a patch before so I want to make sure Im doing this right
23:21 imirkin: Satchelboi: https://www.mesa3d.org/submittingpatches.html
23:21 Satchelboi: imirkin: Whoops, thank you!
23:22 imirkin: skeggsb: btw, this works on the nv42/mpeg: https://github.com/imirkin/linux/commit/4bd17b0d1e9957db9d7dc01136cb3b5e7170d9ad
23:22 imirkin: feel free to redo this by checking for the engine == &nv40_mpeg -- it seemed like that would end up clunkier than the chipset check. although i know you've tried to avoid them.
23:23 imirkin: (esp since it ends up being &nv31_mpeg...)
23:32 Satchelboi: Quick question on something I noticed now too: How come on the Nouveau freedesktop home page, Mesa is still shown in version 13.0.3 if we're in 17.0.3 now?
23:38 imirkin: RSpliet: actually it's not your patches that caused that... those messages were there before
23:40 imirkin: Satchelboi: versions don't update themselves.
23:41 imirkin: i think i'm just going to remove the version column. it doesn't help anything.
23:43 AndrewR: hi imirkin! I haven't reassembled my nv43/AGP machine yet..sorry. Just tried mesa-git on nv92, and either I need X restart, or my card is again not right kind of nv50 (for shader-clock thing))
23:43 imirkin: AndrewR: well, the patch above worksforme on a NV42/PCIe
23:44 imirkin: AndrewR: the shader clock stuff did work OK on my G92
23:44 imirkin: the existing piglit tests require compute, i did mail one that use a fragment shader
23:44 imirkin: (i've already pushed the shader clock patches btw)
23:46 AndrewR: imirkin, ah, sorry they are in GL_ARB_shader_clock
23:46 AndrewR: https://pastebin.com/0ggW7HzW
23:46 imirkin: right ...
23:46 imirkin: (sorry, i don't get it)
23:52 imirkin: ok, this is pretty unbearable... the GT 240 with GDDR5 really doesn't work with display and graph both using vram at once. guessing there's a good bit of init missing there =/
23:52 imirkin: RSpliet: want me to do anything while i have it plugged in? otherwise i'm going to swap it out