00:58airlied: skeggsb: might want to take those rpm fixes
00:58skeggsb: airlied: ah, i was mostly waiting for someone who actually wrote that code to comment - i've never touched it :P
00:59skeggsb: the discussion on the last posting didn't seem to have a solid conclusion
01:03airlied: skeggsb: consider this an acked by :)
02:14DanaG: I'm trying to get a DRI_PRIME setup going between nouveau and qxl (via the modesetting driver, because qxl can't be a provider of any sort)... and for some reason, the nouveau X driver refuses to try to use my GPU. The kernel driver works fine, and glmark2-es2-drm shows that OpenGL is working.
02:14DanaG: Video card: 00:10.0 VGA compatible controller : NVIDIA Corporation GK106 [GeForce GTX 650 Ti] [10de:11c6] (rev a1)
02:16DanaG: Xorg log: http://paste.ubuntu.com/21357581/
02:17DanaG: xorg.conf (has commented-out remnants of other approaches): http://paste.ubuntu.com/21357619/
02:17DanaG: About the most I can get is for a single 'modesetting' instance to bind to the nvidia card.
02:18DanaG: dmesg excerpt: http://paste.ubuntu.com/21357795/
03:37urjaman: btw just fyi; I tried to (to satisfy my curiosity i suppose) to figure out what was preventing the kicad opengl view from working on the FX...
03:39urjaman: Namely it seems to be missing atleast non_power_of_two textures and GL_MAX_DRAW_BUFFERS_ARB >= 3 (is 1)
03:40skeggsb: the hardware doesn't support either of those things
03:40urjaman: then i investigated whether i could try it on the blob... found out the 173.x drivers are so old I'd need to downgrade my X ... not feeling like that right now
03:40urjaman: then found a glxinfo dump from an FX running the blob
03:40skeggsb: i *think* the binary driver emulates npot to some extent
03:40urjaman: then i figured out that even that doesnt atleast endorse npot
03:41urjaman: but OTOH, kicad doesnt check, it just tries to get a texture of the viewport size...
03:42urjaman: so I'm guessing it wouldnt run on the blob either, but thats a guess ... so good for a "we only need OpenGL 2.1" app vs a card that is advertised as 2.1 :P
03:43DanaG: (Side note with my VT-d and Nouveau: <middle finger> NVIDIA for actively blocking the use of non-quadro cards with the binary driver under VT-d.)
03:44DanaG: Good thing I didn't actually give nvidia any money for that card -- grabbed it from the "stuff to get rid of" pile at work.
03:46DanaG: It still seems weird to me that the nouveau kernel driver picks up the video card properly, yet xorg can't find a device (and indeed doesn't even claim to support all the devices the man page says it supports).
03:49airlied: if you are passing it through you might need to specify an xorg.conf to find it
03:49airlied: with BusID lines
03:49DanaG: I pasted a few bits of info during the time your connection was presumably dead. let me re-paste as one message.
03:50DanaG: I'm trying to get a DRI_PRIME setup going between nouveau and qxl (via the modesetting driver, because qxl can't be an xrandr provider of any sort). For some reason, the nouveau X driver refuses to try to use my GPU. The kernel driver works fine, and glmark2-es2-drm shows that OpenGL is working.
03:51DanaG: Video card: 00:10.0 VGA compatible controller : NVIDIA Corporation GK106 [GeForce GTX 650 Ti] [10de:11c6] (rev a1 Xorg log: http://paste.ubuntu.com/21357581/ xorg.conf (with commented-out remnants of other approaches): http://paste.ubuntu.com/21357619/ dmesg excerpt: http://paste.ubuntu.com/21357795/
03:51airlied: just a device section with driver nouveau, and I think the busid is in decimal
03:51airlied: not hex
03:51airlied: so BusID "PCI:0:16:0"
03:51DanaG: aah, busid in decimal... that may be my entire problem.
03:56DanaG: Yup, now it binds -- thanks!
03:56DanaG: Also, all the "prime" things seem to assume that people will only ever want to mirror to an Intel device. I tend to want to do more unusual things, like mirroring to the qxl device or an ASPEED device (but ASPEED cannot be an offload sink).
03:57airlied: those things aren't sane
03:58airlied: you'd have to copy using the cpu, it wouldn't be pretty unuseable
04:00DanaG: What ever happened to the nicer things like the 2D-only-Radeon BMC chips?
04:00DanaG: Windows 10 has built-in cross-device clone. I once tried cloning between a 7970 and the ASPEED. It worked... but very slowly.
04:11DanaG: Hmm, it started now, but then locked up with a small spew of: nouveau 0000:00:10.0: gr: ILLEGAL_MTHD ch 11 [003f4a3000 gnome-shell] subc 3 class 902d mthd 1510 data 726f6620
04:14DanaG: Correction: after restarting Xorg, now it's a large spew.
05:13DanaG: hmm, now I have some issues with QXL and modesetting, but I'm not sure which channel is the most relevant.
05:14DanaG: [drm:qxl_enc_commit [qxl]] *ERROR* head number too large or missing monitors config: ffffc900003c6000, 0
05:14DanaG: hmm, maybe I should give up on the bizarro DRI_PRIME hackery and go with making the VM multiseat, instead.
17:05Akien: Hm, nouveau is no longer listed in `xrandr --listproviders` on my optimus laptop (kernel 4.7.0, nouveau 1.0.12, drm_nouveau 2.4.70, xorg 1.18.4), any advice on how to debug that?
17:08Lekensteyn: Akien: have you tried restarting X?
17:09Akien: Lekensteyn: Not yet but I intend to, just waiting for a the upload of a big github repo to finish :D
17:09Lekensteyn: I found that nouveau is sometimes not picked up (maybe because it is resuming?) during start of X
17:26karolherbst: Akien: it doesn't matter with dri3 anyway
17:27karolherbst: and for dri2 offloading to work, nouveau has to be loaded while X is starting
17:37Akien: karlmag: Ah thanks, I had not yet noticed that the dri3 method worked for me
17:37Akien: karlmag: sorry, wrong ping
17:37Akien: karolherbst: ^
17:38Akien: Let's try a reboot to see if dri2 offloading gets fixed
17:45Akien: Hm, still not properly loaded it seems
17:45karlmag: Akien: yeah... karolherbst hates me for that after I started hanging here ;-) (or everyone else does - take your pick :-D )
18:15karolherbst: karlmag: I don't hate anybody :p
18:16karolherbst: and usually I also don't talk to myself either, so I couldn't care less
18:17karlmag: karolherbst: hehe.. I know... 'tis was a joke ;-)
18:20karolherbst: yeah like I was super serious here myself
19:49karolherbst: so, tomorrow won't be my nouveau day, because something came in between. That's starting like planned already!
21:21mwk:played an actual sound using NV1's PAUDIO
21:21imirkin_: found the palette?
21:23karolherbst: mwk: whow, awesome, I totally forgot that even old gpus could do stuff like that
21:24mwk: yeah, fun
21:24mwk: now if only I had some idea of how the notifiers work
21:24karolherbst: once I had a gpu with a scart port :)
21:24karolherbst: crazy thing
21:25mwk: I can only fit 0.5MB of audio in VRAM, which is like 2.5 seconds at CD rate
21:25karolherbst: well, should be enough, right?
21:25mwk: if I find out how to work the buffers, yes
21:26karolherbst: is only a special reason for audio or can you swap the buffers on the fly?
21:26mwk: as in, I need to find out when one of them is empty and refill it
21:26karolherbst: I see
21:26mwk: karolherbst: I can play audio from anywhere in VRAM or system RAM
21:26mwk: hell, this thing can even walk page tables to find audio
21:27karolherbst: well, then why not just leave it in sys ram?
21:27mwk: but I can't use system RAM without writing a kernel space driver
21:27karolherbst: ahhh, I see
21:27karolherbst: doesn't support nouveau those yet?
21:27mwk: NV1? you must be joking
21:27karolherbst: I have no clue
21:28mwk: oh wait
21:28mwk: I can use its DMA capabilities to DMA from a Tesla's VRAM
21:28mwk: that's going to be fun
21:29karolherbst: nv4 is the earliest card supported?
21:29mwk: there's a hw mixer on this thing
21:29karolherbst: and nv1 is that much different?
21:29karolherbst: uhh, nobhody does hw mixing anymore :/
21:30mwk: and every active voice is double-buffered
21:30karolherbst: at least for consumer grade stuff
21:30mwk: so I can swap things whenever I want, no real-time requirements
21:31mwk: karolherbst: you think hw mixing is cool? NV1 has a MIDI synthetizer...
21:31karolherbst: I had an atari with crazy shit midi sound :D
21:31mwk: but that's *not* going to be simple to handle
21:32karolherbst: and with crazy shit I meant like a real mixer application where I could throw stupid stuff at the hw midi thing, so awesome
21:32mwk: I need to fill out a 0x3c-byte voice structure for a simple PCM playback
21:32mwk: most of them involves buffer handling
21:32mwk: but MIDI voices involve a 0x7c-byte structure
21:33imirkin_: are you working this out cold, or looking at traces?
21:33mwk: filled mostly with unknowns at this point
21:33mwk: imirkin_: I'm looking at disassembly of Win95 driver
21:33mwk: <3 VxD
21:33karolherbst: yeah, it may be hard finding a working linux driver for those cards
21:33mwk: it, very conveniently, contains the names of all object classes and some methods
21:34mwk: except all objects except some graphics ones are implemented in software
21:34mwk: so I basically have to trace their code and find out where shit ends up
21:35mwk: as for tracing... let's see, I would have to run Win95 on one of my machnes and somehow add mmiotrace support for it
21:35mwk: or at least port libpciaccess
21:36mwk: this is... yeah, I like disassembling the highest tree in the forest with this herring, thank you very much
21:36karolherbst: mh, could mmiotrace work on top of a vt-d passthroughed gpu?
21:36karolherbst: most likely not
21:36karolherbst: but maybe it would
21:36mwk: *shrug* I don't have hw for that either way
21:37karolherbst: well, it would be a good idea to mmiotrace current windows drivers too
21:37karolherbst: hey mupuf :p
21:37karolherbst: if we plan pimping up reator at some point, mind if we get some vt-d ready stuff working? :D
21:37mwk: anyhow, NV1 is fucking crazy
21:38mwk: and its Win95 driver doubly so
21:38mwk: [and its DOS drivers quadruply so]
21:38karolherbst: but it was a start somehow
21:38mwk: the object system has to be the craziest
21:38karolherbst: times where z-blitting was a uber feature :)
21:38karolherbst: wait, that was earlier It hink
21:39karolherbst: not sure
21:39mwk: and... yeah, it's THAT different from NV4
21:39mwk: even from NV3
21:39mwk: NV3 is a very sane card
21:40imirkin_: how does it differ from nv4? totally different command submission right?
21:40mwk: NV1 from NV4?
21:40imirkin_: nv3 vs nv4
21:40mwk: NV3 vs NV4... the main difference is command submission, yeah
21:41mwk: NV1 has only a PIO mode, the user pokes the FIFO area, and every poke turns into a command
21:41mwk: and it's horrible in many ways
21:42mwk: the main problem is that only one channel can have pending commands at a time
21:42mwk: so... you look at FREE register, see that you can write to the FIFO, get context-switched away, someone else sees that they can write to the FIFO, they write to the FIFO, they context switch back to you, you write to the FIFO, and *boom*
21:43mwk: your pokes now land in the RAMRO, ie. commands' hell
21:43mwk: the NVRM will come, gather the pieces, and stuff them back into the FIFO when there's space
21:44mwk: ... unless you have overflown RAMRO too, then you're SOL
21:44mwk: and this PIO mode is present in unchanged form up until NV40s
21:46mwk: heck, it's even present on Teslas in a limitted form, but it's slightly saner there - every channel has its own "pending commands" memory
21:47mwk: NV3 got a DMA mode, but it's sort of crappy
21:47mwk: the NVRM has to trigger DMA fetch manually, by poking lots of PFIFO registers
21:48mwk: there's no channel switching, once triggered, the fetch has to finish before anything else can happen
21:49mwk: NV4 got the auto-context-switchable, user-submittable DMA
21:49mwk: other than that... NV4 and NV3 are pretty similar in their capabilities
21:51mwk: well, NV4 has DX6 and dual-texturing, and can render to textures
21:52mwk: oh, and NV4's PGRAPH doesn't need as many diaper changes from NVRM
21:53mwk: on NV3, all DMA object binds had to go through software
21:54mwk: and color format changes, and blend VS logic op changes, and...
21:55mwk: so eg. if you wanted to upload R5G5B5 and R8G8B8 images from host, it's faster to create two SIFM objects, set R5G5B5 color format on one, R8G8B8 on the other
21:55mwk: if you use one SIFM and use the SET_COLOR_FORMAT method, it's going through software
21:56mwk: same if you want to render D3D triangles using textures from different DMA objects
21:58mwk: oh, and switching rendering targets on NV3 is quite horrible... there is a class that can set address/pitch of a surface, but there's no protection on that
21:59mwk: so if you have access to the class, you can render to anyone's VRAM; if you don't, you get to ask NVRM for surface rebinds
22:00mwk: at least NV1 doesn't have that problem
22:00mwk: ... by virtue of there not being any alternative surfaces to select from, of course
22:02mwk: the worst thing about NV1 has to be its memory system
22:03mwk: it's so thoroughly inflexible...
22:03mwk: and inconsistent
22:04mwk: it seems that every unit that accesses VRAM on NV1 is batshit crazy in its own unique way
22:04mwk: except PAUDIO, which seems reasonable so far
22:06mwk: so, you want to draw something with PGRAPH... it's rather simple, there's only one surface you can draw to, and it always starts at address 0
22:06mwk: you can select the pitch from one of 8 predefined options
22:08mwk: you can also select bpp... in the scanout configuration
22:08mwk: scanout, on the other hand, has no configurable pitch - it always has to match width * bpp
22:09mwk: in effect, PGRAPH has to be configured to the exact same width and bpp as scanout, or you won't be able to display anything you draw
22:10mwk: and if you happen to set scanout to a different resolution than the 8 predefined ones, you won't be able to use PGRAPH at all
22:11mwk: there's a double-buffering feature, though... just flip one bit and the whole VRAM will be reorganized
22:11mwk: you now have two renderable surfaces on PGRAPH, one at address 0, the other at vram_size/2
22:13mwk: but flipping that bit changes RAMIN addressing, and you invalidated every object in there... not a problem of course, it's not like you can change video settings at runtime under Windows 95 anyway
22:14mwk: then there's PRM aka VGA emulation, and it simply lives on fixed addressing
22:16mwk: emulated VGA memory is at 0, the scanout surface rendered by text mode emulation is at 0x40000, the access log is at 0xe0000, and the VGA register backing storage is at 0xf0000. no way to change any of that.
22:50mwk: I think I know how to loop sound :)
23:19mupuf: All this work really has historical value, this is impressive (as usual) mwk!