03:28imirkin: skeggsb: how are outputs on nv3x selected? i'm having trouble with gl_PointSize outputs in vp, but i don't see where we record basically anything. are they assumed to all always be enabled?
03:29imirkin: (for nv4x we record a vp->or bitmask)
03:30skeggsb: imirkin: i *think* nv30 didn't need enables
07:36orbea: gta san andreas + pcsx2 + nouveau = Entirely playable. :)
11:45ruslan_osmanov: hi, nouveau driver fails to load on kernel 4.6.2 (as well as on 4.4 and 4.5). `dmesg` shows `nouveau 0000:04:00.0: unknown chipset (118070a2)`. It's a laptop with nvidia GM108M [GeForce 940M] + Intel Broadwell-U VGAs.
11:47ruslan_osmanov: well, the module is actually loaded, but the screen is blinking. It's weird that it stops blinking when `glxgears` is running (on the Intel card)
11:48RSpliet: ruslan_osmanov: for the blinking, complain in #intel-gfx. For the nouveau module, I think support wasn't added until 4.7
11:48ruslan_osmanov: RSpliet, thanks
11:48RSpliet: (but don't take my word on it, I recall there being insufficient testers to verify the differences between GM108 and other GM10x cards)
11:49RSpliet: send the intel-gfx people my regards, I experience similar issues on my laptop :-P
11:50RSpliet: in all fairness, it's unlikely that the NVIDIA GPU is any faster than the Intel GPU with current nouveau, given how we don't touch it's clocks
15:46CapsAdmin: i'm trying to use the nouveau driver on my gtx970 and so i'm using mesa 12.1, installed the firmware needed. using kernel 4.6 my screen turns itself off and so i don't know how to view logs and whatnot lol
15:47CapsAdmin: if i boot into 4.7 rc4 i get "Direct firmware load for nvidia/gm204/gr/sw_nonctx.bin failed with error -2" which makes the nouveau driver fail to load (if i understand it correctly)
15:52RSpliet: CapsAdmin: I think there's some patches on the way to fix the screen turning black in either 4.7 or 4.8 (gnurou?)
15:54CapsAdmin: RSpliet, but this is caused by an error right? i'm wondering how to get that error once the screen has gone black
15:55CapsAdmin: or are you saying the error i get in 4.7 is probably the same error i get in 4.6 except it doesn't go black? or fall backs to something
15:58imirkin_: CapsAdmin: do you have the firmware actually there?
15:59imirkin_: CapsAdmin: pastebin the output of "ls -lR /lib/firmware/nvidia"
16:02CapsAdmin: imirkin, https://gist.github.com/CapsAdmin/b660dd08e3556a1239e15c5859cbc52a
16:03CapsAdmin: the linux firmware git repository has a makefile which copies all of it to the appropriate places
16:03imirkin_: and now for the million dollar question
16:03imirkin_: are any of these files available at the time that nouveau loads?
16:04CapsAdmin: like they're on a different drive or something?
16:04imirkin_: like you're using some helpful distro
16:04imirkin_: which makes it easy for you to swap a high-end raid controller into your laptop
16:04imirkin_: and still be able to boot from it
16:04CapsAdmin: i'm using kde neon which is based on ubuntu
16:04imirkin_: but in exchange, the boot sequence is super-complicated
16:04CapsAdmin: but it's all on the same drive
16:05imirkin_: are you familiar with initramfs?
16:05CapsAdmin: no raid or anything like that
16:05CapsAdmin: not really
16:05imirkin_: did you build your own kernel?
16:05imirkin_: and, more to the point, are you using an initrd that has the nouveau module on it?
16:05CapsAdmin: no i got the prebuilt ones for ubuntu
16:05imirkin_: there's some thing you have to do to get firmware onto the stupid initrd then
16:06imirkin_: but i don't use ubuntu, nor do i have any interest in learning how to operate it
16:06imirkin_: it's all too complex for me
16:06imirkin_: i stick to things i can understand.
16:11CapsAdmin: imirkin, maybe i should've used the offical non free firmware package lol
16:11CapsAdmin: so what do you use then? to me it's all the same except i have to type dnf instead of apt or whatever
16:13imirkin_: i use gentoo, but more importantly i build my own kernel tailored to my hw and no initrd's.
16:13imirkin_: [except on my full-disk encryption setups, where the initrd is constant and doesn't have any kernel- or module-specific items]
16:24imirkin_: anyways, chances are you need the firmware to exist in your initrd
16:24imirkin_: no clue how one does that on ubuntu.
17:56gregory38: Is it possible to use concurrency feature of piglit with nouveau ?
17:56gregory38: (deqp too)
17:57imirkin_: possible, but rather dangerous
17:57imirkin_: skeggsb claims that it basically works for him now (with highly-recent kernels)
17:57imirkin_: but i still have my doubts
17:57imirkin_: since every time he's asserted that it worked, it crashed my box hard when i tried it
17:58imirkin_: but assuming he's not pranking me, it must work in _some_ setups
17:58gregory38: I never manage to get it working
17:58imirkin_: what kernel are you on?
17:59imirkin_: i think many of the concurrency fixes only went in around 4.4 or 4.5
17:59imirkin_: ah, that should be recent enough
17:59imirkin_: what issue do you run into? context switching dies a fiery death?
17:59gregory38: Even on a 16 logical core CPU
17:59gregory38: I didn't try recently
17:59gregory38: but last time, I kind of crash/hard lock the kernel
18:00imirkin_: there are allegedly still some bugs left in context switching which could mess things up
18:00gregory38: or maybe it was with Nvidia
18:00imirkin_: nah, nvidia recovers
18:00imirkin_: (or at least did)
18:00gregory38: I don't remember
18:00gregory38: I just remember that my machine require a manual reboot
18:01gregory38: Anyway, I will take the slow but safe way
18:01imirkin_: right. i just don't run piglit
18:01imirkin_: much faster that way.
18:01imirkin_: i don't test often, but when i do, it's in production! :)
18:02gregory38: Well never hurt to validate my patch
18:03gregory38: just need to wait the end of the test to get back my keyboard input !
18:05imirkin_: oh, coz of the stupid windows popping up?
18:05imirkin_: run with PIGLIT_NO_WINDOW=1
18:06imirkin_: (stupid nvidia...)
18:06gregory38: yes windows popping up
18:06imirkin_: (or use the gbm piglit platform)
18:07gregory38: Ah nice it works better
18:07gregory38: Doesn't work for deqp stuff
18:07gregory38: thanks you
18:07imirkin_: i've played this game before :)
18:08imirkin_: i can only imagine someone trying to do this with twm...
18:08imirkin_: [which requires manual placement of every new window]
18:09gregory38: could be interesting
18:09imirkin_: are you messing about with validation?
18:10gregory38: No, just the sso validation of sampler
18:10imirkin_: ah fun
18:10imirkin_: btw, feel free to implement GL_KHR_no_error - that's a fun one ;)
18:11gregory38: yes this one would be fun
18:11imirkin_: there's a trivial impl which is to neuter _mesa_error
18:11gregory38: with all the context stuff
18:11imirkin_: but then you can also pick various places and just skip expensive checking
18:12gregory38: well I'm not sure the checking is that expensive
18:13gregory38: I have the feeling the toggle of state to upload a texture is kind of killer
18:13gregory38: and cso doesn't come free
18:14gregory38: by the way I wanted to ask you something
18:14gregory38: Program reference resources
18:14gregory38: but does draw call reference program
18:14gregory38: or does it use a kind of bind program
18:15gregory38: and then draw reuse the binded program
18:17gregory38: my hw feeling would be that draw calls have N handler to the program of the pipeline
18:41imirkin_: sorry, not sure what you're asking
18:44gregory38: let's take a basic example
18:44gregory38: do a draw with program 1
18:44gregory38: and then do a draw with program 2
18:45gregory38: how do you configure the hardware to use the program1 and then later the program 2
18:45imirkin_: i flip the relevant stage's START_ID to point to one or another offset in the code segment
18:45imirkin_: (assuming that both have previously been compiled and uploaded before that point in time)
18:46gregory38: start id are a parameters of the commands
18:46imirkin_: START_ID is a method which is invokable via the fifo command submission mechanism
18:46imirkin_: which is the primary way for the host to communicate with the gpu
18:48gregory38: so you send first those command to select the program
18:48imirkin_: largely they're just setters for internal values which are looked up when you hit the big green "go!" button
18:48gregory38: and then you send the go
18:49imirkin_: with a modest amount of error checking
18:50gregory38: ok. Thanks for the info, I will grep around :)
18:54imirkin_: stuff like texturing/images works very differently on fermi vs kepler+ btw
18:54imirkin_: (kepler+ is all bindless, while fermi is all binded)
18:55imirkin_: (well, there's still a texture/sampler descriptor table you have to set, but no binding table)