00:02 Lyude: airlied: ahhhh, that makes sense
01:45 imirkin: Lyude: srcs = inputs, dsts = outputs
01:46 imirkin: Lyude: unfortunately the src's are a little freeform wrt the various flags that can be set
01:46 imirkin: Lyude: and furthemore, the lowering pass adjusts them from "normalized" into "what the hw wants", after which it's even harder to recover the data if you need it
01:47 imirkin: Lyude: there are a ton of comments here: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp#n825
01:47 imirkin: however those comments kinda pre-suppose that you know what tex instructions are... :)
01:47 imirkin: there are a ton of options, and some are mutually exclusive =/
02:05 imirkin: Lyude: then there's the annoying bit of encoding the src's into the actual instruction... since you can only have 2 args, it's encoded as 2 groups of up-to-4 args. of course which args fall into which group (i.e. how they're split) also varies from gen to gen
02:06 imirkin: Lyude: as for the dsts, it's quite nice since you're able to e.g. make red + alpha output go into 2 sequential registers -- basically you provide a mask which says which components go into (incremental) registers
09:50 m4sk1n: hi
10:45 m4sk1n: I have gt920M, how can I contribute to nouveau? I'm not good programmer
10:45 m4sk1n: I use Arch Linux
11:13 RSpliet: m4sk1n: sorry, right now the biggest thing we need is developer effort. there's quite a todo list already.
11:15 RSpliet: I'd encourage you to try and improve dev skills through nouveau ;-) but otherwise the best contribution is being a good civilian by testing what you expect to work (so not necessarily for features like OpenCL or perf optimisation... we know!) and report good, complete bugreports if it doesn't
14:03 sodapop: hi, X hangs when I use qemu (dual monitor setup). From the log: nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
14:04 sodapop: any quick fix
14:26 ccaione: guys, is this known? https://paste.fedoraproject.org/paste/6tRA8XYtO1oVZzxY3rsil15M1UNdIGYhyRLivL9gydE=
14:26 ccaione: nvidia NV118
14:27 ccaione: reproducible on the latest master also
14:41 RSpliet: ccaione: that... is new to me
14:42 ccaione: nice :(
14:42 RSpliet: didn't happen on a 4.10 kernel?
14:42 ccaione: RSpliet: according to the report (I do not have the machine) this is reproducible on 4.8, 4.11 and 4.12-rc3
14:43 RSpliet: oh you have a report... you asked whether it's known or not. If there's a report, then obviously yes ;-)
14:43 ccaione: RSpliet: internal report :D
14:43 ccaione: ;)
14:43 RSpliet: Better make it public on freedesktop
14:44 ccaione: yeah, I'll do
14:44 RSpliet: unless you have a Red Hat subscription, then using the internal channels might give you priority
14:44 RSpliet: (the Red Hat path)
14:44 RSpliet: because... the lead dev happens to be on RHs payroll
14:45 ccaione: nope, but it has been just posted to nouveau@lists.freedesktop.org and dri-devel@lists.freedesktop.org already
14:45 RSpliet: bugzilla is more trackable than mailinglist - see https://nouveau.freedesktop.org/wiki/bugs
14:45 ccaione: yup, sounds good
14:45 RSpliet: oops
14:45 RSpliet: https://nouveau.freedesktop.org/wiki/Bugs/
14:46 RSpliet: also, include more log. It looks like something might be going wrong earlier (detecting 0MiB of RAM is an obvious problem)
14:47 RSpliet: also, NV108 != GF108
14:48 RSpliet: oh... wait I'm mixing up two reports now
14:50 RSpliet: sodapop: random hangs occur - the context switching engines reporting problems are believed to be a symptom of something not context-switching related, the newer the kernel the less likely they are
14:52 RSpliet: ccaione: did you turn off compiler optimisations for this kernel?
14:53 RSpliet: and I mean -O0 or something like that
14:53 RSpliet: oh never mind
14:54 RSpliet: I'm being stupid - again
14:54 RSpliet: either way, yes, this is a symptom of detecting 0MiB of RAM
14:55 RSpliet: it would be good for nouveau to bail in this case before doing something stupid like a div-by-zero, but that doesn't mean there's not something bigger wrong
14:59 sodapop: RSpliet, I use 4.10.17_1 GTX660 and it happens only at random when I do some mouse activity within qemu window
15:00 RSpliet: sodapop: search through our bugzilla, there's plenty of covfefe on the CTXSW_TIMEOUT symptom. Chime in with your "this is how its reproduced" and maybe we can find a useful pattern. So far though, we're in the blank too as to why this happens
15:01 sodapop: ok cool
15:01 sodapop: thanks
15:01 RSpliet: (and with an average kernel developer count of 1 and a lot of issues, a bit low on progress. Sorry, devs are welcome!)
15:02 sodapop: 1? :(
15:02 RSpliet: on the kernel side
15:03 RSpliet: maybe 1.1, some people here have made a few bursts on certain corners
15:03 RSpliet: the userspace side is more like 1.5
18:09 sodapop: the nvidia firmware blob + nouveau affects desktop graphics too or only video accel (vdpau etc.) ?
18:13 karolherbst: only video accel
18:13 karolherbst: except you also use the gr firmware
18:14 sodapop: gr firmware?
22:31 Lyude: imirkin: think you could help me understand some nouveau code regarding a commit you made? apparently 8e7893eb53213254997a1a3beb0575be11821f83 ("nvc0: add support for BGRA8 images") is breaking some stuff with pbos: https://hastebin.com/eludododov.txt
23:03 fitzgen: Hello! Can anyone tell me if this is a good graphics card to get if I want mesa + nouveau to work well? https://www.newegg.com/Product/Product.aspx?Item=N82E16814487295
23:04 fitzgen: please and thank you :)
23:04 fitzgen: imirkin: I was told that you were probably the best person to ask, if you're around
23:05 nyef: A GTX 1050?
23:06 nyef: Isn't that one of the ones that needs unreleased firmware, or am I misremembering or behind on news?
23:07 fitzgen: it seems to be listed here: https://nouveau.freedesktop.org/wiki/CodeNames/#NV130
23:08 Lyude: gtx 1050 is not one you want for good support
23:08 Lyude: honestly if you want good support, don't go nvidia
23:08 Lyude: 760 is probably one of the better ones to get, but it is more trouble then it's worth if you just want a good gpu to use on linux
23:08 fitzgen: Lyude: what would you recommend in its place?
23:09 Lyude: fitzgen: I personally use an R9 380
23:09 fitzgen: I need mesa to be able to debug servo under rr
23:09 Lyude: amdgpu works wonderfully out of the box, and is an upstream driver
23:09 Lyude: so no blobs, good performance, etc etc
23:09 fitzgen: do those use mesa? (I'm generally ignorant of this stuff)
23:09 Lyude: yep :)
23:09 fitzgen: cool, I'll dig into it, thanks'
23:10 nyef: I'm currently running a GTX 750 Ti on my test desktop, but I really don't stress my test machines very much.
23:10 Lyude: np
23:10 Lyude: yeah, I think the 760's are ok with nouveau because they're reclockable iirc
23:10 Lyude: and 750, anything from that gen
23:18 imirkin_: Lyude: what hw is that on?
23:19 imirkin_: sodapop: some GTX 660's are known to hang with nouveau ctxsw fw, but work with blob ctxsw fw.
23:19 imirkin_: fitzgen: you have to better define "work well". for most definitions, i'd say "none"
23:20 imirkin_: note that GTX 750 (Ti) is not in the kepler generation but rather in the maxwell generation
23:21 imirkin_: ccaione: there have been some updates to VRAM detection on GM107+ (as well as GF108, amusingly enough). perhaps your board is affected by that.
23:22 imirkin_: ccaione: alternatively there could be an issue in how we bring the board out of sleep, and fail at it (like we used to with GK10x's a while back)
23:22 imirkin_: and so various things get read back as 0 when they should have values
23:22 imirkin_: Lyude: i remember someone saying that BGRA8 images were broken on fermi...
23:22 imirkin_: Lyude: i wouldn't object to just reverting that commit tbh =/ although understanding why the fail would be nice.
23:24 Lyude: imirkin_: i'm for reverting it as well just because it is breaking glamor pretty badly
23:24 imirkin_: moral of the story: don't use glamor.
23:24 imirkin_: glamor shouldn't be used by default
23:24 Lyude: it's breaking glamor because pbo's no longer work, but ok
23:24 Lyude: anyway
23:24 Lyude: there are some things I noticed
23:25 Lyude: mainly: there's no parts of the code at all that set the format->bgra variable you call in NVC0LoweringPass::convertSurfaceFormat
23:26 imirkin_: ssssssssssshoot.
23:26 imirkin_: no wait
23:26 imirkin_: wait
23:26 imirkin_: lies
23:26 imirkin_: damn lies
23:26 Lyude: am I wrong? i couldn't find anything searching for "bgra ="
23:27 imirkin_: [hold on]
23:27 imirkin_: const struct TexInstruction::ImgFormatDesc TexInstruction::formatTable[] =
23:27 imirkin_: ...
23:27 imirkin_: { "BGRA8", 4, { 8, 8, 8, 8 }, UNORM, true },
23:27 Lyude: OH
23:27 Lyude: that makes sense, ok
23:27 imirkin_: "true" == "format->bgra"
23:27 imirkin_: if (format->bgra) {
23:27 imirkin_: std::swap(typedDst[0], typedDst[2]);
23:29 nyef: ... Is there some way to turn that true into bgra = true and still have it compile?
23:29 imirkin_: .bgra = true
23:29 nyef: (Largely to make it easier to grep for)
23:29 imirkin_: with C99 initializer
23:30 Lyude: either way though, think we might be able to revert that for the time being? or at least disable it for fermi, I don't think it's breaking any of the later generations
23:32 imirkin_: i vote for disable on fermi
23:32 imirkin_: should be easy enough in is_format_supported
23:32 Lyude: cool, I will go come up with something to disable this and send it to them l
23:32 Lyude: *ml
23:33 imirkin_: RSpliet did report some other glamor issues with Xwayland...
23:33 imirkin_: but i have no interest in supporting glamor anywhere
23:33 Lyude: feel free to link them to me, I've been working on trying to clean all of that stuff up for work
23:33 imirkin_: [esp not on X]
23:34 Lyude: btw, this isn't glamor on x :P. we still default to non-glamor for fermi on X, even in fedora
23:34 imirkin_: i thought it got flipped
23:34 Lyude: it did for later gens
23:34 imirkin_: ah
23:35 imirkin_: [that convertSurfaceFormat thing is pretty hairy... that was some nicely packed code i wrote... heh.]
23:36 Lyude: good to know I wasn't the only one who got confused reading that, lol
23:36 imirkin_: it handles every format in that code
23:37 imirkin_: based on the data from ImgFormatDesc
23:37 imirkin_: calim had originally done it with dedicated functions for every format
23:37 imirkin_: [in the relevant assembly]
23:38 imirkin_: i figured that was going to be a pain to maintain though
23:42 imirkin_: that said... from nvidia's docs...
23:42 imirkin_: #define NV90C0_SET_SU_LD_ST_TARGET_FORMAT_COLOR_A8R8G8B8 0x000000CF
23:43 imirkin_: which maps to #define G80_SURFACE_FORMAT_BGRA8_UNORM 0x000000cf
23:43 imirkin_: so ... it should work :)
23:43 Lyude: hehe
23:43 imirkin_: but obviously who knows =/
23:47 imirkin_: that format only matters for storing stuff, of course
23:47 imirkin_: not for reading
23:47 Lyude: yeah, nvidia uses bgra8 internally on their hw don't they?
23:48 imirkin_: hm?
23:48 imirkin_: i just mean the image format that's programmed into the binding is only used for imageStore()
23:48 imirkin_: not for imageLoad()
23:48 Lyude: ah
23:48 imirkin_: since the decoding has to be done "manually" for loads
23:49 imirkin_: wait a sec....
23:49 imirkin_: WAIT A SEC
23:50 Lyude:waits
23:50 imirkin_: grrrr
23:50 imirkin_:is slow
23:50 imirkin_: so it's all well and good that i have that if (bgra) swap()
23:50 imirkin_: but ... that doesn't actually do anything :(
23:51 Lyude: code doesn't get called? I noticed that but I figured i was just not running a test that actually invoked an surface format conversion
23:51 imirkin_: no, it gets called
23:51 imirkin_: but swapping the locations of those 2 array things does absolutely nothing.
23:51 imirkin_: it needs to be done *before* the for loo
23:51 imirkin_: loop*
23:51 Lyude:tests
23:52 imirkin_: mystery remains why fermi is the only one affected
23:52 imirkin_: i think it might be coz BGRA8 is only supported on fermi?
23:53 Lyude: hrm, changing that doesn't seem to affect that test at all. that was the same test that I never saw calling that function though
23:53 imirkin_: (a) git diff
23:54 imirkin_: (b) NV50_PROG_DEBUG=1 output for that test
23:54 Lyude: (a) https://hastebin.com/agageyomik.cpp diff
23:55 imirkin_: [hm, no, looks like BGRA8 images are supported everywhere. very odd.]
23:55 Lyude: https://hastebin.com/boxavotazi.txt
23:55 Lyude: (b)
23:55 Lyude: oh darn, it didn't strip the ascii formatting one sec
23:56 imirkin_: right, so it's a pbo
23:56 imirkin_: and it's using a shader to store the image
23:56 imirkin_: so the load stuff doesn't matter here
23:57 imirkin_: and it manages to store all 0's
23:57 imirkin_: irrespective of what the color is supposed to be
23:57 imirkin_: which isn't great.
23:57 imirkin_: it could, of course, be the texfetch that's wrong
23:57 imirkin_: but that seems less likely.
23:57 imirkin_: ok, one quick test...
23:58 imirkin_: if you edit ....
23:58 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c#n1003
23:59 imirkin_: after unsigned rt = ...
23:59 imirkin_: if (rt == 0xCF) rt = 0xD5;
23:59 imirkin_: and see if you just end up with color-swapped outputs instead of all-0 outputs