01:20gQuigs: happy to do further testing to move my bug# https://bugs.freedesktop.org/show_bug.cgi?id=106227 along.. If anyone has some ideas
02:07gQuigs: oh, and sorry for the double p5000 discussion.. that's my fault
02:13imirkin: gQuigs: that GPU just comes up broken
02:13imirkin: gQuigs: Apr 24 22:59:31 desktop kernel: nouveau 0000:1c:00.0: DRM: GPU lockup - switching to software fbcon
02:13imirkin: right on start
02:19gQuigs: imirkin: Is that odd? I would somewhat expect more (or hope for) of an error message
02:19imirkin: like what... "oooh noooooo!!!! what a world?!"
02:20imirkin: we submitted commands to the GPU and it does not appear to be executing them
02:21imirkin: oh, iirc karol had a similar problem
02:21imirkin: with a hilarious solution... hold on
02:22imirkin: hmmm... can't find it
02:22imirkin: but basically GR had to get reset or something
02:22imirkin: karolherbst: --^
02:22skeggsb: if it were karol's problem, you'd see more error messages than that
02:23imirkin: iirc GP107 also had messed up firmware originally
02:23imirkin: but i would assume that'd be rare
02:23imirkin: [one would have to have gotten a problem checkout from like 6-12 months ago]
02:25gQuigs: I've used the card with the nvidia prop. driver too.. I may have tried dev Ubuntu with nouveau 6-12 months ago though
02:25imirkin: gQuigs: right, the proper sequence of commands would wake it up from its deep sleep
02:28gQuigs: is it failing on commands related to : Console: switching to colour frame buffer device 240x67, or something else? how would I see?
02:29skeggsb: it's impossible to say, it could be anything. if the driver was aware of something more specific wrong, it'd report it... that message alone is just a "the gpu stopped processing commands for *some* reason"
02:30skeggsb: i have a bunch of fixes to our graphics engine init pending that may or may not help, hopefully i'll push those out at the end of the day
02:31gQuigs: understood, will definitely give them a try, thanks :)
11:48tagr: karolherbst,imirkin, skeggsb: seems like the 406040 error is gone now (Linux 4.16.6, Mesa 18.0.2)
11:48tagr: no idea what caused it to get fixed, though, but I haven't seen the symptoms in 2 days
12:04mupuf: tagr: cue the symptoms in 2 seconds
12:04tagr: mupuf: =)
12:05PaulePanter: Should Nouveau also accept Option ROMs, which are not a multible of 4 KB?
12:07imirkin: tagr: some slight random cahnge in timing? who knows.
12:08imirkin: PaulePanter: well, the _ROM interface stinks
12:09imirkin: we just fetch 4K at a time
12:09imirkin: until we can fetch no more
12:09PaulePanter: imirkin: Looks like. To support older Linux kernel versions, coreboot needs to be adapted anyway. Just wanted to be sure.
12:10imirkin: afaik it's not nouveau using the interface weird
12:10imirkin: it's the interface that's weird
12:10imirkin: you should be able to find some _ROM implementations in various bugs
12:10imirkin: we *try* to fetch it all in one go btw
12:10imirkin: which many ACPI _ROM implementations support
12:10imirkin: but then we fall back to the slower 4k-at-a-time
12:11imirkin: PaulePanter: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_acpi.c#L388
12:12imirkin: len = min(len, (int)obj->buffer.length);
12:12imirkin: so you should be able to return fewer than 4K bytes
12:12imirkin: however note that the _ROM isn't quite supposed to be the contents of the option rom
12:12PaulePanter: imirkin: Can I paste your comments as a review comment?
12:12imirkin: the latter ones are the more accurate ones :)
12:13imirkin: i.e. the ones from *after* i read the code rather than the ones where i was going by memory
12:13imirkin: this is the code that drives that interface: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
12:14imirkin: the interface is you return 4K at a time, until you run out, at which point you return a lower length
12:14imirkin: if you're returning 4K even though you've only filled 1K of data, that's a problem
12:15imirkin: and also *ideally* you handle any size in the request, not just the interface spec's maximum of 4K
12:16PaulePanter: Thank you.
12:40sigod: hi, im having random Xorg crashes with nouveau, the Xorg.0.log error is "nouveau flip queue failed" and journalctl say fifo:SCHED_ERROR
12:41sigod: im using 1.0.15-2
12:50imirkin: sigod: what kernel / gpu?
12:50imirkin: sigod: also pastebin xorg log
12:50imirkin: are you using blob ctxsw fw?
12:50sigod: dont think so
12:50imirkin: have you in the past come in here reporting such an issue?
12:50imirkin: (your handle seems mildly familiar)
12:51sigod: maybe but its the first time ive found the error
12:51imirkin: well, some people with GTX 660's have had trouble with the nouveau ctxsw fw
12:51sigod: i was asking about hardware acceleration for vpdau the other day
12:51imirkin: and it seems like some people have had luck with the blob ones
12:52sigod: SCHED_ERROR 0a [CTXSW_TIMEOUT]
12:52imirkin: if you extract the firmware frmo 325.25 exactly
12:52imirkin: then you will also get the various gr fw.
12:52imirkin: if you move all that into place, and boot with nouveau.config=NvGrUseFW=1 then it should load that fw
12:53sigod: oh ok
12:56sigod: so its nvidia creating problems again
12:56imirkin: well in this case solving them :)
12:57skeggsb: nope, it's us this time, our fw doesn't work properly on some gtx660.. for unknown reason
12:57imirkin: one could argue that nvidia created the gtx 660 and thus problems, but ... :)
12:58skeggsb:wishes we could use C to write the ucode
13:00imirkin: skeggsb: i saw a falcon compiler attempt in one of the envytools repos
13:00imirkin: dunno how far it had gotten. i think mwk's?
13:00skeggsb: yeah, iirc mwk was writing one, but stopped :P
13:00skeggsb: i already tried it
13:00skeggsb: not quite working well enough to be usable
13:01imirkin: with judicious use of __asm__ perhaps/
13:46tagr: would it be possible to add a falcon target to LLVM?
13:47imirkin_: i think it's been tried
13:47imirkin_: in theory, sure
13:47imirkin_: but someone who likes llvm a whole lot would have to do it :)
13:48tagr: there's a few people here that do a lot of work with LLVM, maybe they'll fall in love enough =)
13:49imirkin_: looks like mwk tried it -- http://0x04.net/~mwk/Falcon.html
13:51imirkin_: i think that's mostly the spec, but i think he had an impl too
14:18HdkR: tagr: How much do you love LLVM? :)
14:24tagr: HdkR: not very much =)
14:25HdkR: I've found in the past that it is quicker to write a new backend in to GCC, but it is a nicer in the long run to use LLVM
14:26HdkR: I've also been writing a couple LLVM backends in the past few months and they are a bit of a time suck
14:33karolherbst: HdkR: well if you compare to GCC that is ;)
14:34karolherbst: I think if you don't need all the frontends supported, then it doesn't matter anyway
14:34karolherbst: but yeah, for the falcons we kind of want to do that with llvm or gcc
14:35karolherbst: tagr: llvm https://github.com/envytools/llvm/commits/falcon
14:35karolherbst: clang https://github.com/envytools/clang/commits/falcon
14:35karolherbst: lld https://github.com/envytools/lld/commits/falcon
14:36karolherbst: tagr: but yeah. It would be awesome to have llvm target for falcons
14:36karolherbst: and it would be nice if nvidia would support/maintain it as well :p
14:37tagr: karolherbst: yeah, that would be nice, but I don't hold your breath =)
14:37karolherbst: yeah, I know
14:38karolherbst: I think it is semi public that there might be plans to move away from the falcons anyway? nvidia gave some talks on risc-v about that I think?
14:40HdkR: Says it within the first minute :)
14:43mwk: yeah, I got interrupted before it was usable
14:43mwk: I suppose I should finish it some day
16:34sigod: ok i just installed the nouveau-fw package and enabled the kernal module parameter, how do i know if it's working?
16:49imirkin_: sigod: it should say "using external firmware" on boot or something like that
18:16nikk_: Hello imirkin, for this task https://trello.com/c/YnhHNblO/100-nv50-nvc0-fix-fbo-blending-formats-glrgb10 we had a few questions.
18:20adya: We went through the file: https://github.com/imirkin/mesa/blob/master/src/gallium/drivers/nouveau/nvc0/nvc0_state.c and we think that the patch we are supposed to write is in the else block(if indep_funcs is false).We found the locations of other macro definitions in nvc0_stateobj.h file, but we are unable to correlate between 'NVC0_3D_BLEND_EQUATION_RGB' and 'BLEND_EQUATION_RGB'. The first problem we are facing is in locating the 'BL
18:25adya: We have looked into the following header files: nvc0/nvc0_stateobj.h, pipe/p_defines.h, nvc0/nvc0_context.h, nvc0/nvc0_query_hw.h, nvc0/nvc0_3d.xml.h, nouveau_gldefs.h, but we have not found it. We did find the 'NVC0_3D_BLEND_EQUATION_RGB', however, we cannot figure out how this nvc0_2d is removed entirely, as specified in the nvc0_compute.xml.h description. Could you guide on how this 2d definition is used in the code in nvc0_state.
18:29adya: Also, we think that changes are to be made in the definition of nvgl_blend_eqn() function defined in nouveau_gldefs.h and in the BLEND_FUNC_DST_ALPHA. Is this a viable approach?
18:29imirkin_: i'm confused ...
18:29imirkin_: so if you look at the NVC0_3D() macro, you'll see that NVC0_3D(foo) will reference NVC0_3D_foo
18:29imirkin_: i forget where that blend equation stuff is defined
18:30imirkin_: but all you need to do is say that if it's == DST_ALPHA, then set it to ONE
18:30adya: Ok, so we do have to refer to the NVC0_3D function and check if it's value is set to DST_ALPHA, and then set it to 1
18:31adya: Is that correct?
18:32imirkin_: you have to look at the blend settings
18:32imirkin_: and if the blend settings are s.t. any of the blend functions is DST_ALPHA
18:32imirkin_: *and* if the RT in question is RGB10X2
18:32imirkin_: then you should set the blend function to ONE
18:32imirkin_: this is all a bit tricky
18:33imirkin_: since currently blend states are in a CSO
18:33imirkin_: and this would be a fixup on top of such a CSO
18:33imirkin_: given that this will NEVER happen in practice
18:33imirkin_: you can just do the fixup after the cso is applied and then mark blend state as dirty so that it's re-emitted on next draw
18:36adya: Oh so we found that the blending happens when the factors are set in nvc0_blend_fac() and nvc0_blend_create(). The create function has the cso passed to it. So I think we should pass the DST_ALPHA value set to 1 as an attribute of cso,whenever it is passed to the create function?
18:37imirkin_: you should not touch the cso.
18:37imirkin_: well, maybe add a property to it or something
18:37imirkin_: which is like "DST_ALPHA used, be careful"
18:37imirkin_: and then at validate time
18:38imirkin_: you'd check if FB | BLEND is dirty
18:38imirkin_: in which case you'd check if any bound fb's are RGBX10
18:38imirkin_: and if the cso indicates that "careful" bit
18:38imirkin_: and if so, flip the relevant blend function for the relevant RT to ONE
18:38imirkin_: and mark the blend state as dirty
18:39imirkin_: errr ... that second part doesn't have to happen actually
18:39adya: Oh okay! The bound fb's are the 8 indices of rt right?
18:39imirkin_: yes, cbuf[i] == rt[i]
18:41adya: yes! That clarifies our doubt! I had interpreted the cso incorrectly. Thank you so much imirkin__. We'll work on the pointers that you have given and revert with more questions!
18:41nikk_: Thank you imirkin_! We'll get back with the completed task soon!
18:41imirkin_: feel free to post partial patches that you think are on the right track
18:41imirkin_: i can probably glance at them very quickly and given initial reactions
18:41nikk_: yes okay!
18:42imirkin_: (post == provide hastebin links to)
18:42adya: Yes that would be great!
18:42adya: Yes sure!