10:48pmoreau: karolherbst: More like, I need to check what happens with sat to make sure the patch is complete. :-)
12:55rhyskidd: any review takers for: https://patchwork.freedesktop.org/patch/171427/ ?
12:55rhyskidd: a simple documentation improvement in nouveau
13:00imirkin: pmoreau: no need to go crazy with it
13:01pmoreau: imirkin: No one’s gonna stop me!! :-D
13:01pmoreau: imirkin: I just don’t want to stop halfway through it. :-)
13:40pmoreau: rhyskidd: Done. I was wondering about adding TK1+, as mupuf pointed out.
13:42rhyskidd: thanks. I'll respin the patch with the TK1+ qualification added
13:42pmoreau: But, on the other hand, we do not give an upper limit on which cards are supported. And given how it is going with new cards, it’s not looking good.
13:44rhyskidd: however, the lower limit here is caused by some pretty major architectural differences pre TK1; different to just an inability to bring up essential Falcons
17:35belzurix: I know that there is no support for SLI in nouveau and the reason is stated on the webpage. I'm thinking about setting up an sli system (2×GTS 250) at home and I could test stuff on it. I'm not into computer graphics and I don't think this would be of any priority, but I thought I should tell you about it (at least, the webpage says I should).
17:38imirkin: SLI is a very tricky problem to do anything useful with at the driver level
17:39imirkin: esp with modern games
17:39imirkin: GTS 250 ... that's usually a G92 i guess? should work mostly OK, just don't try h.264 vdpau decoding.
17:40imirkin: i should just disable the bsp engine on there by default so people don't hang their boards unnecessarily.
17:55imirkin: belzurix: dunno if your client timed out before my comments, if it did, check logs (see topic)
17:56belzurix: Yeah, I had some freezes with hardware decoding but I could live without it so I left the problem alone. Yesterday I plugged in a 750 Ti ( GM107 - I tested it for a friend for whom it didn't work) and it worked out-of-box ( there were performance issues because I unified the current G92's and the GM107's output ), but it was awesome to see that now nouveau can do even this. That's when I thought about buying another card to help SLI te
17:56belzurix: (I checked the logs)
17:56imirkin: GM107 doesn't support video decoding accel with nouveau
17:57imirkin: but otherwise should be moderately well supported
17:58imirkin: fwiw we largely know how SLI works. just a matter of putting that knowledge to use which is harder than it sounds.
17:58imirkin: there recently was an ext made by nvidia which largely reflects how SLI works and lets applications use it directly
17:58imirkin: which bypasses the issue of the driver divining what it is that the application wants
17:58RSpliet: imirkin: I suspect it's no longer true scan-line interleaving?
17:59imirkin: RSpliet: it never was on nvidia
17:59imirkin: that was just on voodoo2
17:59RSpliet: (happen to have a link? Could be an interesting read if I fail to fall asleep)
17:59imirkin: well it's a little scattered
17:59imirkin: mwk documented how to set up the P2P link between SLI slave/master
17:59belzurix: imirkin: thx for clarifying
18:00imirkin: and you can look at command submission for how to decree that a command is executed on one or another or all cards
18:00imirkin: (there are bits in the pushbuf command thing)
18:00RSpliet: imirkin: ... and then they share address spaces to avoid uploading textures and buffers twice?
18:00imirkin: well - the memory stuff is the bit i'm least familiar with
18:01imirkin: i don't think a GPU can reference another GPU's memory. but i could be wrong.
18:01imirkin: the SLI link also, i think, allows some "fast" transfer between GPUs. again, i don't know any of the details of that.
18:01imirkin: it's mostly allowing a single command stream to execute on each GPU
18:02imirkin: and i guess yeah, the master GPU will distribute commands over that SLI link
18:02imirkin: and i wouldn't be surprised if it were able to "share" some of those DMA reads somehow. dunno.
18:02RSpliet: I imagine you'd want a fast path to share the results of the "rasteriser" with both GPUs
18:03RSpliet: Sounds like something very tedious to get right in the driver - mirroring address spaces and everything
18:03imirkin: not aware of such a thing.
18:03imirkin: not to mention figuring out how to distribute the work
18:03imirkin: e.g. if a later render uses current render as a source, etc.
18:03imirkin: and you split things by e.g. left/right
18:03imirkin: or any other scheme
18:04imirkin: it made more sense in single-pass renderers
18:05RSpliet: Which in my mind is still how everything works. Oh I wish I had time to actually learn GL
18:06RSpliet: SLI is probably not the topic to start with :-D
18:06imirkin: well, the way to think about it is... imagine a ray tracer
18:06imirkin: the more bounces you trace through the better it works
18:06imirkin: the way GL renders isn't exactly analog to that
18:06imirkin: but it gives you some intuition for why multi-pass makes for prettier pictures
18:07RSpliet:looks up the noun "bounce"
18:08RSpliet: I appreciate your attempt imirkin, but I'm afraid I need to start learning from step one - triangles :-P
18:08imirkin: the idea of a ray tracer is that you send light rays from a viewport
18:08imirkin: and see where they land
18:08imirkin: with a reflecting surface, that light ray will bounce
18:08imirkin: with some attenuation/etc
18:08RSpliet: Ahh, like that, yes, that makes sense
18:09imirkin: you could keep tracing that poor light ray ad-infinitum, which could take a while
18:09imirkin: so you'll often limit it somehow (e.g. strength, distance, quantity of bounces, etc)
18:10imirkin: similarly, there's only so much "fanciness" you can have with a single-pass renderer
18:10imirkin: even though there are tons of cheats involved
18:10imirkin: (like, say, textures)
18:10imirkin: (and pre-computed normals)
18:11imirkin: raytracing is a much more logical way of doing things, but also much more cpu intensive. hence the GL approach with triangles, etc
18:11imirkin: if you want to better understand how a rasterizer works, i'd highly recommend trying to read through 'swr' source -- it's surprisingly readable and commented
18:12imirkin: i got a much more complete appreciation for wtf barycentric coords are that way
18:12RSpliet: I thought I found a very elaborate document on that a while ago...
18:12imirkin: and what all this 'ij' business is, and why flat/perspective are a thing
18:12RSpliet: a series of blog posts
18:12imirkin: (or rather, not why, but how)
18:13imirkin: yeah, but when it's broken and you're trying to fix it, you tend to figure things out a lot better than reading some lengthy blog
18:13imirkin: [in this case, some clipping-related items were broken]
18:14belzurix: imirkin: the G92 in question (which I'd like to buy) has an issue: the current owner cannot game on it, but it does everything else, even video decoding. I'm guessing it might have a VRAM or heat problem. Does hardware decoding stress the ram or anything on the card? (producing heat, using vram)
18:14RSpliet: this series looks familiar - not sure if it's whats in the back of my head
18:14imirkin: belzurix: the reason that hw video decoding doesn't work on G92 is that we are not correctly setting up the BSP chip.
18:15imirkin: has nothign to do with vram
18:16imirkin: RSpliet: looks like a good one.
18:16belzurix: so I cannot guess the card's problem with only this much info
18:17imirkin: RSpliet: 192317dfeb8c9223b702196e0c8e8c555c24b844 -- that was a fun one to track down :)
18:17imirkin: belzurix: seems unlikely you'll ever be able to find out, even if you have it in your hands
18:17imirkin: belzurix: could be a temp issue
18:17imirkin: G92's get hot, and this is the age of shoddy solder connections
18:18imirkin: (more of a G84/G86 thing, but who knows)