03:57imirkin: oh interesting. i wonder if we're running over with blits, coz we assume that someone had clamped them down....
04:00imirkin: BootI386: ping me when you come back. i think i know what's going on. but i don't want to test coz i don't have a second box handy to kill the process from.
05:10imirkin: BootI386: https://github.com/imirkin/mesa/commit/27d6af5953aaa6030fd5fcc33866b1f1b1e3427a
05:10imirkin: totally untested.
06:15imirkin: ok. mildly tested now.
09:00BootI386: imirkin: Sadly it still crashes :(
11:26RSpliet: mupuf: we did know about the post-reclock script... figured that one out a long long time ago and got abandoned before 2nd gen Tesla
11:27RSpliet: The "Noise-Aware PLL Table" is interesting though, might solve the well-known problem of screeching PLLs
11:29mupuf: yeah, I remembered the reclocking script
11:29mupuf: but there are loads of things we may have to deal with here
11:30RSpliet: lots of it is pre-Tesla
11:31RSpliet: Heh, yes or the very very new stuff indeed. All the low-power tables/scripts could be interesting
11:32RSpliet: The "Ventura" table is ace though...
11:32mupuf: RSpliet: you stole my joke!!!
11:33RSpliet: Oh hadn't seen that... great minds
11:33mupuf: RSpliet: I kept it to myself ;)
11:34RSpliet: I don't have quite such self restrain
14:46karolherbst: pmoreau: slct $r0d eq $r2d $r4d %r7
14:47karolherbst: r7 == 0 ? $r2d : $r4d
14:47karolherbst: dTy is 64 bit, sTy is 32 bit
14:48karolherbst: slct is a bit weird because you have two source types, but one of the is equal to the dest type
14:48karolherbst: so sType is the type of the value compared with 0
14:56karolherbst: pmoreau: and why do you want to hide the NIR support behind the env var?
14:57karolherbst: this would make it messy do have global enabled spir-v through nir, but glsl still defaulting to tgsi
14:57karolherbst: or having the spir-v extensions + glsl -> TGSI
14:58karolherbst: the env var doesn't enable NIR, it just tells gallium to prefer nir over tgsi
15:16imirkin_: karolherbst: slct can't do dual-width sources
15:19karolherbst: imirkin_: right, that's why it gets lowered into two slcts
15:19aldr: im trying to install envytools but i'm a little bit stuck
15:21imirkin_: karolherbst: excellent :)
15:21aldr: I followed the steps by installing every missing package when running cmake CMakeLists.txt
15:21karolherbst: imirkin_: I hope the last source won't be ever 64 bit...
15:21imirkin_: aldr: i dunno that anyone *installs* envytools
15:21imirkin_: you just build it and run it in place
15:21karolherbst: but then I ran some OpenCL kernels and got also a shift with a 64 bit shift....
15:21imirkin_: karolherbst: definitely not
15:21imirkin_: yeah, shifts are 64-bit in tgsi too
15:21imirkin_: (they didn't use to be)
15:21aldr: there I have hit a brick wall it says phton or cython are not installed, but I checked I installed both
15:22karolherbst: imirkin_: yeah, not in nir
15:22imirkin_: but then the amd guys changed it
15:22imirkin_: and i had to rewrite the thing =/
15:22karolherbst: 64 bit lowering?
15:22aldr: should I try older versions, currently I have a bare debian strech installed
15:22aldr: yeah by installing I mean of course building it
15:22karolherbst: aldr: well, a make install should work quite well already
15:23karolherbst: well you need the dependencies
15:23karolherbst: dev packages or whatever
15:24aldr: yeah that much I figured but unfortunately the error massage isnt very obvious at least not for me gogling it didnt help me fix it either
15:24karolherbst: imirkin_: anyway, I have my desktop system now and can debug all kind of weirdo bugs
15:25karolherbst: and of course I just went ahead and installed plasma, so this will be fun I guess
15:27imirkin_: aldr: search for like "debian development packages"
15:28imirkin_: they have some thing that's the equivalent of apt-get useful-things-that-everyone-should-have
15:29aldr: thx Ill try that
15:33imirkin_: aldr: apparently there's a "apt-get build-dep" which installs packages you need to build the package given (this is of little direct help to you)
15:33imirkin_: aldr: there's also a build-essential pseudo-package
15:33imirkin_: you should really ask in a debian-focused chan though
15:33karolherbst: imirkin_: well that doesn't help with a missing cython dep though
15:33imirkin_: we just do nouveau here.
15:34imirkin_: karolherbst: it helps because what's missing is e.g. "python-dev"
15:34imirkin_: coz they split everything
15:34imirkin_: to complicate everyone's lives
15:34imirkin_: they're optimizing for the 0.0001% who want the super-minimal thing
15:34karolherbst: yeah, but that python thing is a mess
15:35mooch2: okay, so ptimer now works in my emulator
15:35mooch2: fully tested and shit
15:35mooch2: thank GOD
15:36aldr: yeah of course but apt-get tells me that cython AND python ANDpython ist already the newest version installed
15:36aldr: thats why I was asking here
15:36imirkin_: mooch2: at this rate you should be getting to pascal pretty soon :)
15:36imirkin_: aldr: python-dev
15:36karolherbst: or python3-dev :p
15:36imirkin_: aldr: for all i know there's some other package though. like i said... i'm not a debian person
15:36karolherbst: do we use python3?
15:36imirkin_: this shit Just Works (tm) on gentoo
15:36mooch2: imirkin_, nah m8
15:36mooch2: still on nv3
15:37mooch2: nv4 still doesn't work AT ALL
15:37aldr: yeah and its also not python3-dev and not python-dev
15:37aldr: cause they are also all installed
15:37karolherbst: as I said, python is a mess here
15:38karolherbst: we don't know the answer
15:38aldr: thats why I was asking here
15:38aldr: I fugured that much karol :D
15:38karolherbst: if a distribution makes life hard for you, ask them :p
15:38imirkin_: mooch2: i was being ... optimistic
15:38mooch2: imirkin_, still trying to figure out why xf86-video-nv won't send any commands other than method 0
15:39mooch2: with param 0x80000000???
15:39karolherbst: does the driver even work on real hardware?
15:39aldr: well my guess was that debian isnt the most scarce linux distribution and that I might get all stuff that I need cause I read it on the nouveau landing page somewhere
15:40aldr: but thanks for ur trys anyways
15:40karolherbst: I think 0% of drm devs use debian
15:40karolherbst: maybe there is one though
15:40mooch2: karolherbst, it should
15:40mooch2: it was made by nvidia
15:41mooch2: yes, it works on real hardware, i've used it on my gentoo machine with an nv3t
15:42karolherbst: well, the feature set of nv was.... limited at best
15:42karolherbst: it was just written so that somebody could install the nvidia driver, right?
15:44karolherbst: or maybe it was a more serious driver on those first GPUs?
15:45mooch2: it did 2d accel
15:45mooch2: that's about it
15:46karolherbst: yeah, I am mainly wondering how well it runs on modern kernels and so on, because they dropped support in like 2010 or something, right?
16:16mooch: karolherbst, i'm running debian 6 man
16:16mooch: in the emulator that is
16:16mooch: so, not exactly a modern kernel lol
16:29karolherbst: mooch: I see
16:37karolherbst:is wondering when we see P2972 Nouveau changes
16:40mooch: da hell
16:41mooch: i just wish someone experienced with the nv3 could take a look at my code and figure out da hell i'm doing wrong
16:41cyndis: karolherbst: will need to fix GP10B first :p
16:41karolherbst: cyndis: :D good to hear
16:42karolherbst: cyndis: you know of some secboot related issues? Because I have some with my pascal GPU and was wondering if it might be the same on the GP10B
16:42mooch2: for some reason, it just hangs before sending any graphics commands
16:43cyndis: I don't think it's related to secboot, it was working before, the current failure I'm seeing is failure to create GP100_COMPUTE_CLASS object or something like that
16:43cyndis: also Thierry had some FB_TIMEOUT issues
16:44karolherbst: ohh I see
16:44karolherbst: wasn't the compute class thing fixed?
16:44cyndis: maybe, I was testing with Thierry's mesa branch which might not be the latest
16:44cyndis: I should try to rebase that
16:45karolherbst: I know that this stuff works on a normal Pascal GPU
16:45karolherbst: and I doubt anything is different on the graphics side between those and the GP10B
16:45mooch2: gp10b is tegra x2, right?
16:45mooch2: i wish nvidia would just hurry up and give me nv3 docs already
16:45karolherbst: cyndis: allthough, we use GP104_COMPUTE_CLASS on non GP100 chips
16:46cyndis: karolherbst: I'm not actually 100% sure if it was GP100_COMPUTE_CLASS, I used a minimal amount of time on it yesterday evening :p
16:46cyndis: I should take another look
16:46karolherbst: ahh I see
16:47karolherbst: but maybe that meas branch just contains the GP100 stuff and that's why it fails ;)
16:47imirkin_: mooch2: i doubt those docs ever existed
16:47mooch2: early drivers reference a technical manual
16:48imirkin_: this might come as some surprise, but when companies are starting out, writing great docs is rarely #1 on the list of priorities
16:48mooch2: well, then how am i supposed to write the emulation for this thing?
16:48mooch2: i still have no idea how to do context switches, other than mwk's code
16:48mooch2: which i'm not sure i rewrote correctly
16:48karolherbst: how are we supposed to write the nouveau driver without documentation :p
16:49karolherbst: mooch2: mhh, maybe you could mmiotrace that stuff? would be fun
16:50karolherbst: ohh wait, there is no driver doing stuff
16:50mooch2: well, shit, apparently, i have a bug in my ramht lookup code
16:52mooch2: welp, i'm a dumbass
17:00cyndis: karolherbst: well.. it's working now :)
17:01cyndis: GP100_COMPUTE_CLASS was working, and GP104_COMPUTE_CLASS not. I'll have to check why that is the case and if that's right (I'm not very familiar with the driver)
17:07mooch2: had to implement the pio free register
17:10karolherbst: cyndis: ahh I see
17:10karolherbst: cyndis: maybe GP10B is just more close to GP100 in this regard
17:11cyndis: that is likely, the Tegra GPUs tend to be quite early and close to the x00 chips aiui
17:12karolherbst: cyndis: I assume you just hacked the stuff up in mesa for now?
17:12karolherbst: patch for this should be trivially upstreamable, I can take a look and push it if it is fine
17:12cyndis: sure, I can write it as well, either way is fine for me
17:13karolherbst: well, I assumed you would write it, I would push it :p
17:13cyndis: ah, terminology mismatch :)
17:13cyndis: sure, I'll do that
17:14karolherbst: mupuf: I think you broke nacklight stuff on the lenovo P50 :p
17:14mupuf: karolherbst: oh, how?
17:14karolherbst: mupuf: in 4.13
17:14karolherbst: maybe the LED stuff
17:14karolherbst: still bisecting, but your stuff was close enough
17:15karolherbst: or maybe something else... I will see the result shortly
17:17karolherbst: mupuf: lucky you, it was skeggsb :p
17:17mupuf: karolherbst: hehe
17:17karolherbst: ahh the nvkm_ior port
17:20karolherbst: 2 steps left
17:24mupuf: backlight testing would be a lot of fun to automate
17:25karolherbst: well, in this case it is easy, because the sysfs files are gone
17:25mupuf: although, we could test the SW by checking the HW state...
17:25mupuf: yeah, nouveau really needs to get some testing ;D
17:25mupuf: that is going to be a hell of a lot of work
17:25karolherbst: mupuf: some people will write you after some 7.5 release I've heard :p
17:28mupuf: Let's see if I can get cibuglog open sourced before that :D
17:29karolherbst: now... how does this make sense
17:31karolherbst: mupuf: any idea why that commit breaks it?
17:32mupuf: karolherbst: better read the condition for enabling backlight
17:32mupuf: you'll probably need a couple of printk and you'll see which one fails
17:33karolherbst: I am sure this one fails: if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(nv_encoder->or)))
17:37karolherbst: mhh, maybe I made a mistake though
17:37karolherbst: and maybe it is a random thing..
17:39karolherbst: oh well, I will take another look tomorrow
18:39orbea: is wine-d3d9 supposed to work with nouveau?
18:40imirkin_: generically, yes
18:40orbea: Cool :)
23:05imirkin_: BootI386: so, i wasn't able to repro the crashes with your application and DRI3 with my patch. i haven't tried without, but it may be that there's something else going on. e.g. do you have a compositor?
23:12BootI386: imirkin: Only xinit, Xorg, xterm, mutter, my test program and my stress script are enough
23:13imirkin_: remind me what mutter is?
23:13imirkin_: is it a redirecting compositor?
23:13imirkin_: ah yeah. it's a redirecting compositor.
23:17imirkin_: so perhaps that's the bit that i'm missing to repro
23:17imirkin_: let's throw an assert into nouveau's blit impl...
23:17imirkin_: that makes sure that shit isn't out of bounds
23:25imirkin_: BootI386: can you do that yourself? in nvc0_surface.c i think
23:25imirkin_: look for nvc0_blit()
23:25imirkin_: make sure that the src box isn't out of bounds of the src surface, and dst box isn't out of bounds of the dst surface
23:26BootI386: Yeah, sure, let's try it!
23:45orbea: so finally was able to test wine-d3d9 with a game that is reported to work with what I presumw is amd at winehq, but it just gets stuck after the splash screen with just a mouse cursor and a black screen. The wine output says d3d9 is active. Where would I start to debug this?
23:45orbea: it works without d3d9, but some areas are slow and winehq says d3d9 fixed it for other people
23:46imirkin_: try #d3d9
23:46orbea: okay, thanks
23:56BootI386: *digging through headers and structs*
23:59BootI386: That helps :)