05:07 almeida1: once again, the read port muxes and write port's keeps two states, it's functionality means/equals that alu does not execute unless value was changed, in case of pointer it caches on chip the last address, as i said i ignore optamill munchers, and a clown like imirkin should be ignored my anyone too
06:19 almeida1: when you had a pointer that means persistent reg/dest address is unique , allthough it is unique in any case, than still what is the problem to overwrite the address in pointer case provided that writebacks are ignored?
10:14 martossa: more precicely param_decoder in reg_256x32b_3r_1w adds a mask for current wavefront vgpr_base, other then the current will have no wr_en and fetch the last value, than it flips the whole wavefront regs to alus while writeback broadcasting is only one to one of them later
10:14 martossa: done
10:23 martossa: in other words, as in glsl spec, if one of the operands like RHS is whole array, the operation is also whole-array
10:32 martossa: so nutters, if you want to say/show something legally sane to me, first go exchange your goat brain against something that i have
10:53 martossa: If the LHS array was not declared with a size, it takes it size from
10:53 martossa: * the RHS. If the LHS is an l-value and a whole array, it must be a
10:53 martossa: * dereference of a variable. Any other case would require that the LHS
10:53 martossa: * is either not an l-value or not a whole array.
11:16 tagr: imirkin_, mwk, karolherbst: yeah, kusma and digetx are the ones to talk about the old GPU, they know them fairly well at this point
11:17 tagr: as for video decode, that's completely unrelated to the GPU on Tegra124 and earlier, only starting with Tegra210 does it become similar to the decoding found on desktop GPUs
11:42 karolherbst: imirkin_: currently running the CTS and 3.0 and 3.1 are failing for stupid reasons: geometry/tesselation/compute shaders not working :)
12:12 mwk: tagr: alright, thanks
12:12 mwk: yeah, I spent the last night cataloguing the various GPU/vdec units on Tegras :p
12:13 mwk: lots of weird shit
12:14 mwk:wonders about all the strange host1x client
12:14 mwk: like EPP... what does that thing actually do
12:14 mwk: or ISP
12:14 mwk: also, the ARM7 vector coprocessor looks... intriguing
12:15 mwk:wonders if it has anything to do with VP1/VP2
12:34 tagr: mwk: it's not actually a vector coprocessor, it's called AVP and that stands for Audio-Video Processor
12:35 tagr: mwk: it's primarily used for early boot, to bring up the Cortex CPUs
12:36 tagr: and then during normal operation it typically runs a firmware that can be used to decode video
12:37 mwk: and how would that be related to VDE?
12:37 tagr: the hardware to decode video is separate IP that is accessible from the Cortex CPUs as well, though, so currently the tegra-vde driver in upstream Linux accesses that hardware directly, without involving the AVP
12:38 mwk: anyhow, I'm not talking about that
12:38 mwk: I'm refering to VCP2
12:38 mwk: whatever that is
12:38 tagr: mwk: so VDE is the video decode engine on Tegra20 through Tegra124
12:38 tagr: ah... I vaguely remember VCP...
12:39 mwk: so... normally, AVP drives VDE and this is why I can't find any reference to it in official kernels?
12:41 tagr: mwk: yeah, I think the downstream kernels only have a bit of a shim driver that will take a command stream and forward it to the AVP
12:41 tagr: so the AVP firmware implements a command stream interface to the VDE hardware, essentially
12:41 mwk: alright, makes sense
12:41 mwk: oh, and about drivers
12:42 mwk: where can I find the official kernel trees with drivers for tegra?
12:42 tagr: as far as I understand it, the way digetx reverse engineered it was by running a full downstream stack through a Tegra port of qemu
12:42 mwk: upstream does not exactly look complete
12:43 mwk: and I've found several branches with tegra drivers, with varying subsets of implemented functionality
12:43 tagr: he was actually emulating the CPUs and the AVP running the VDE firmware so could capture register accesses from the firmware
12:43 mwk: huh
12:43 mwk: that's heavy
12:43 tagr: quite brilliant, in my opinion
12:43 mwk: yeah, neat
12:43 tagr: which particular Tegra generation are you interested in?
12:44 mwk: all of them
12:45 tagr: mwk: https://developer.nvidia.com/embedded/linux-tegra-archive
12:45 tagr: that should have links to the official releases for all generations, except Tegra114
12:46 tagr: and yeah, upstream is missing quite a few bits, mostly GPU and multimedia on older chips and multimedia on more recent ones
12:46 tagr: and we don't support some of the more exotic stuff
12:46 tagr: EPP and ISP for example
12:47 mwk: "we"?
12:47 tagr: upstream
12:49 tagr: mwk: is this just for "fun" or do you have a particular goal?
12:49 mwk: just for fun
13:37 anierospa: so basically, if you look what the flop_32b does, it has continuous assignments to detect the change via two states, but read muxes have also to states, i can comprehend it fine, but i do not know how to explain.. cont assignment won't do a copy if the two states match, i.e previous and current
13:37 anierospa: to/two
13:37 anierospa: so in the end, it copies only the lanes that changed in a given warp
13:38 anierospa: for an example, if you loaded two reg pointer via lsu
14:46 karolherbst: imirkin: did you look at those packed_pixels.*rectangle tests?
14:46 karolherbst: in the CTS?
15:15 Lekensteyn: Hi, has xf86-video-nouveau been tested with Xorg 1.20? There are at least two suspicious compiler warnings, one related to xorg-server-1.19.0-373-g8e3b26cea and another possibly due to changing header inclusions
15:15 Lekensteyn: nv_driver.c:1443:9: warning: implicit declaration of function ‘wfbScreenInit’; did you mean ‘fbScreenInit’? [-Wimplicit-function-declaration]
15:15 Lekensteyn: drmmode_display.c:697:44: warning: passing argument 1 of ‘PixmapStopDirtyTracking’ from incompatible pointer type [-Wincompatible-pointer-types]
15:36 karolherbst: Lekensteyn: no idea, doubtful
15:36 karolherbst: do other ddx driver have patches to fix stuff up like that?
15:37 Lekensteyn: amdgpu and others needed adjustments from what I can tell based on the "Make PixmapDirtyUpdateRec::src a DrawablePtr" nouveau mailing post from July 2017
15:57 karolherbst: Lekensteyn: ahh
15:59 Lekensteyn: since upgrading to xorg 1.20, I don't get anything on the external miniDP/HDMI screen except for a mouse cursor (PRIME, nouveau is the output source for Intel)
16:06 karolherbst: Lekensteyn: I see
16:07 rhyskidd: mwk: thanks for the review comments on my ctxsw series
16:08 rhyskidd: will respin that
16:09 Lekensteyn: karolherbst: any idea about the possible problem for the observable issue (external monitor issue) and how to approach fixing it? Do you think it is related to the former type change?
16:10 karolherbst: Lekensteyn: maybe? dunno
16:10 karolherbst: never looked into any DDX
16:10 Lekensteyn: ok
16:20 Lekensteyn: I suspect that the issues that people have here are closely related: https://bugs.freedesktop.org/show_bug.cgi?id=100086
18:17 matryoshka: Question: I have an optimus laptop and would like to better manage its power (specifically while on battery); I would like to have my discrete gpu disabled by default and only turn it on when programs require it
18:17 matryoshka: do i need to install anything? bumbleebee? I've found conflicting info regarding bumbleebee: some say i should use it, some say nouveau does all that is necessary by default..
18:42 karolherbst: matryoshka: depends
18:42 karolherbst: do you plan to use nvidia or nouveau?
18:42 karolherbst: also on newer laptops all that powering off stuff is broken anyway
18:48 matryoshka: I want to use nouveau
18:50 karolherbst: well yeah, then it should just work
18:50 karolherbst: except you have one of those laptops where it doesn't
18:57 matryoshka: thanks karolherbst; I'll go check how it handles just nouveau
20:58 kiljacken: I'm having problems with nvkm_falcon_v1_clear_interrupt timing-out on a 1070Ti (GP104), anybody around who can point me in the right direction?
21:02 kiljacken: Increasing the timout duration from 10ms to 1s doesn't do much, so I'm assuming the underlying issue is more hairy
21:19 karolherbst: kiljacken: mhh, are you able to compile your own kernel?
21:22 karolherbst: kiljacken: this patch might help you: https://github.com/karolherbst/linux/commit/876bac36abf66b15986e2a3dafd5afc7dd0048e2
21:30 kiljacken: I've got the module compiling locally, I'll give it a spin
21:31 karolherbst: ahh, okay
21:32 karolherbst: I have to use that patch on my machine, but never actually figured out what the real issue is :(
21:32 karolherbst: all that secboot stuff is.... silly
21:32 karolherbst: at least I assume that's your issue
21:32 karolherbst: kiljacken: do you maybe have a full dmesg or something?
21:33 kiljacken: karolherbst, the patch didn't help much. let me upload the dmesg somewhere, just a minute
21:34 kiljacken: https://gist.github.com/kiljacken/2eb2cbf6784569ac89e897f08c2a7104
21:34 kiljacken: A tad bit long, but the end is right at the trace
21:41 karolherbst: kiljacken: uhm, sure that you use an external module?
21:41 karolherbst: because it loads the kernel one
21:41 karolherbst: or do you mean you compile the entire kernel locally?
21:41 kiljacken: karolherbst, Oh did I upload the old dmesg? I had two file lying around.. Lemme just get the right one haha
21:41 karolherbst: well "drivers/gpu/drm/nouveau/nvkm/falcon/v1.c" is a path inside the linux tree
21:41 karolherbst: not a nouveau git tree
21:42 karolherbst: I just want to make sure I understood you correctly :)
21:43 kiljacken: karolherbst, there we go, fresh dmesg: https://gist.github.com/kiljacken/b3c6b611caed473e27974afa457cb74a
21:44 kiljacken: same thing happens with or without the patch you shared
21:44 karolherbst: okay, yeah, that looks better :)
21:45 karolherbst: well more or less
21:46 karolherbst: kiljacken: if you boot with nouveau.noaccel=1 does it at least get you to boot properly?
21:49 karolherbst: allthough that might not change a thing, because the fbcon thing will still trigger that :(
21:49 karolherbst: kiljacken: the painful part here is, that all that secure boot stuff is quite impossible to debug properly
21:49 kiljacken: karolherbst, noaccel works as expected, but booting is thankfully not a problem. I run off my iGPU and mainly use the dGPU for a passthrough vm
21:49 karolherbst: ohhh
21:49 karolherbst: is this a desktop?
21:50 kiljacken: This is a desktop yea
21:50 karolherbst: okay
21:50 karolherbst: mhh
21:50 karolherbst: maybe you want to blacklist nouveau then if you are not going to use it anyway?
21:50 karolherbst: but yeah
21:50 karolherbst: would be nice to figure out those secboot issues
21:52 karolherbst: kiljacken: I think the best you can do is to open a bug report
21:52 kiljacken: It's bound to vfio-pci by default, so no issues starting normally :) Would be nice if nvidia didn't make it so hard for nouveau, or if amd made competetive hardware
21:52 kiljacken: I'll go post a bug report then :)
21:52 karolherbst: well, that secure boot stuff is quite a pain, and not just for us
21:52 karolherbst: it is not debugable, like physically
21:53 kiljacken: wow
21:53 karolherbst: so you have to be able to sign your own firmware
21:53 karolherbst: and do stupid debug outputs somewhere
21:53 karolherbst: you can't debug the microcontroller if they are doing that stuff, because you can't read out registers or interneal memory and nothing
21:53 karolherbst: not even the program counter
21:54 karolherbst: so you basically know nothing
21:54 kiljacken: that's no fun
21:54 karolherbst: and if something goes wrong? no idea why
21:54 karolherbst: yeah, it is painful
21:55 kiljacken: i'd love to hope that the situation gets better on the next gen of cards, but knowing nv, it's probably not going to be
21:55 karolherbst: well, who knows
21:55 karolherbst: well I wouldn't be able to tell if I would know something anyway :(
21:56 karolherbst: but, I should try to convince some nvidia people to be more helpful debugging that secureboot stuff
21:56 kiljacken: NDAs are lovely
21:58 feaneron: are ndas getting in your way too often these days, karolherbst?
21:58 karolherbst: feaneron: not really, I am good at avoiding those situations
21:58 feaneron: cool
21:59 karolherbst: well I still know a few more things, but it is usually reasonable stuff not to share
21:59 karolherbst: or won't affect anything
21:59 feaneron: but sad that they are there in the first place
22:00 karolherbst: it is kind of understandable though for most things
22:01 gdk: hello. does anyone know how mipmaps works on maxwell gpus? do you need to create one TIC per mip level?
22:05 kiljacken: well, thanks for what help you could give karolherbst! i'd better head of to bed know haha
22:32 pendingchaos: gdk: there is one TIC for all levels, and afaik each mipmap is stored one after another with some padding if needed
22:32 pendingchaos: there seems to be some details in nv50_miptree_init_layout_tiled() in nv50_miptree.c about how things are stored (which should apply for maxwell)
22:32 pendingchaos: also: mipmapping seems to be unsupported for linear textures
22:33 gdk: thanks, I will take a look
22:58 gdk: is it necessary to pass the offset of each level to the gpu?
23:25 pendingchaos: gdk: I don't think so, I haven't seen anything that does
23:25 pendingchaos: imirkin could probably answer for sure