00:35imirkin: pendingchaos: the kepler+ compute thing would be tough. it also includes constbuf bindings iirc, so ... yeah. tough. i'd leave that out for now. the regular graphics pipeline shader headers should be easy though.
00:42karolherbst: imirkin: do you want to take a look at the log2_64 patches or should I just merge those? https://patchwork.freedesktop.org/series/43586/
00:43imirkin: wow, the default patchwork font stinks. i wish they'd stick to 'monospace' rather than messing around with 'Courier New'
00:44imirkin: i'd do that as 1ULL<<32 or something.
00:44imirkin: the lower case l's blend in with the 1 with certain fonts
00:44imirkin: also the shifts don't need to have LL's on them
00:44karolherbst: there is a v2 of the second patch...
00:44imirkin: and pos should be a u32 at most
00:45imirkin: if not a u8...
00:45karolherbst: fun... why doesn't the v2 show up
00:45imirkin: this is for the first patch
00:45karolherbst: imirkin: https://patchwork.freedesktop.org/patch/225145/
00:45imirkin: much nicer.
00:46karolherbst: spacing is crappy to stay consistent with other functions inside that file
00:46imirkin: R-b on both.
00:46karolherbst: okay, thanks
01:38AndrewR: imirkin, hello! I see your patches, should I test them? (currently from new machine)
03:39imirkin: AndrewR: you can if you like. they definitely fix things for me, and i had the same error you did.
04:31pmoreau: “SPH IMAP Definitions” I didn’t know NVIDIA hardware had native support for IMAP protocols! ;-p
04:33imirkin: input map, presumably
04:34pmoreau: Possibly, since there is an omap further down
04:47HdkR: pmoreau: All the terrible mail protocols you could ever need. Supported right in your GPU
04:50imirkin: but where's the pop3 accelerator...
04:53pmoreau: :o It has to be hidden somewhere!
08:52hakzsam: imirkin: I don't remember, sorry
16:26imirkin_: pendingchaos: what's %.8x? i don't remember ever seeing the ....
16:27pendingchaos: on http://www.cplusplus.com/reference/cstdio/printf/: "For integer specifiers (d, i, o, u, x, X): precision specifies the minimum number of digits to be written"
16:28imirkin_: right... but what's the .?
16:28karolherbst: that.s exactly that
16:28imirkin_: does that add spaces in front?
16:28imirkin_: same as %08x?
16:29karolherbst: seems like it
16:29pendingchaos: I think so
16:29imirkin_: hah, ok. just never seen that before.
16:29imirkin_: figured it was something clever
16:29karolherbst: .number is used rather for floats
16:29karolherbst: to specify the max amount of numbers
16:29karolherbst: "For a, A, e, E, f and F specifiers: this is the number of digits to be printed after the decimal point (by default, this is 6)."
16:30karolherbst: works for strings as well, nice
16:30imirkin_: hopefully with spaces :)
16:30karolherbst: the other way around
16:30karolherbst: %.6s is 6 chars max
16:31karolherbst: or until null
16:31karolherbst: defaults to 0 for strings :)
16:31karolherbst: ohh wait
16:32imirkin_: i meant the padding
16:32karolherbst: it always defaults to 0
16:32karolherbst: no padding
16:32karolherbst: for padding you should use %6s I think
16:33karolherbst: but then it doesn't get truncated...
20:52gdk: hello, does anyone know what happen when invalid values are written to the gpu pgraph registers (in particular, the IBLEND registers, the blend equation and factor)?
21:20imirkin_: gdk: usually you'll get an interrupt telling you that an invalid value (or bitfield) was set
21:21imirkin_: something like this: nouveau E[ PGRAPH][0000:03:00.0] DATA_ERROR [INVALID_BITFIELD] ch 6 [0x003f9de000 VBoxCrWinCmd] subc 0 class 0x9297 mthd 0x0810 data 0x20010e0c
21:21imirkin_: [random paste from some random bug somewhere]
21:22gdk: I believe that there are also some registers for enabling or disabling said interrupts?
21:22imirkin_: the on-chip validation is probably less-than-perfect, so ... you can probably fool it
21:22imirkin_: you can mask out which errors get reported to you
21:23gdk: and if you do that I believe that it just ignores the invalid command (as if it was not sent) right?
21:24imirkin_: gdk: well, the validation still happens as before. no one tells you an error occurred
21:24imirkin_: (at least i assume that)
21:24imirkin_: i'm not 100% sure what happens in that case... does the old value stay? is the context in some partial state? no clue.
21:27gdk: ok, thanks
21:31gdk: do you know the difference between the tex and texs maxwell instructions?
21:36imirkin_: gdk: yeah, it's the way that they consume arguments (and provide results)
21:37imirkin_: texs iirc provides 2 dests and 2 sources, so it only works for 1d/1d_array/2d texturing without any funny business like explicit lod/etc
21:37imirkin_: the 2 dests are two-wide pairs
21:37imirkin_: so a total of 4 results
21:37gdk: yep it uses 2 dests
21:37imirkin_: it cuts down on the amount of merged registers, which eases the pain to RA
21:37imirkin_: given that 2d-texture without any funny business is an extremely common case
21:52gdk: tex seems to be basically the same thing
21:53gdk: oh no sorry, tex only has 1 dest
21:54HdkR: gdk: Very similar as to what they do. TEXS is more limited in functionality but more flexible in the registers used
21:54gdk: so if I understand it correctly, RG and BA are written to the two dests (in sequence) on texs, and on tex RGBA is written to a single dest (in sequence aswell)
21:58skeggsb_: gdk: yes. and on volta, all the tex instructions have the two dest regs
21:59imirkin_: gdk: tex also takes quads of source arguments, so each src is actually 4 values
21:59imirkin_: while TEXS it's a single value
22:22gdk: thanks for the help, I think I understand how it works now (except for the parameters lz/lb/ll/lba/lla, still trying to figure out what that means, maybe something related to LOD?)
22:23imirkin_: lz = level zero
22:23imirkin_: lb = level bias
22:23imirkin_: ll = level level (i.e. explicit level)
22:23imirkin_: lba/lla ... i think that has something to do with derivatives
23:54Kevlar_Noir: hello, my nvidia card could only go up to 1019mhz but
23:54Kevlar_Noir: when I see this https://pastebin.com/SiHJ3dAb
23:54Kevlar_Noir: I hesitate to put the pstate to 1
23:56imirkin_: you mean 0f?
23:57imirkin_: well, just because there are cstates doesn't mean they'll necessarily get used
23:57imirkin_: what kernel are you on btw?
23:57imirkin_: and what gpu is this?
23:57imirkin_: ok good. just wanted to make sure you weren't on something old
23:58Kevlar_Noir: the gpu is a kepler : nvidia gtx 750 ti
23:58imirkin_: that's a maxwell
23:58imirkin_: but reclocking should still work on it
23:58imirkin_: i think it's fairly safe to give it a go
23:58Kevlar_Noir: to try the 0f ?
23:58imirkin_: you can check what cstate is used by cat'ing the file again
23:58imirkin_: the last line has the current settings
23:58imirkin_: yeah, try 0f
23:59Kevlar_Noir: and if my gpu go for 1293mhz ?
23:59imirkin_: it's probably fine.
23:59Kevlar_Noir: it's an overclocking
23:59imirkin_: well - try it
23:59imirkin_: you can always go back to 07