01:20 gQuigs: 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:07 gQuigs: oh, and sorry for the double p5000 discussion.. that's my fault
02:13 imirkin: gQuigs: that GPU just comes up broken
02:13 imirkin: gQuigs: Apr 24 22:59:31 desktop kernel: nouveau 0000:1c:00.0: DRM: GPU lockup - switching to software fbcon
02:13 imirkin: right on start
02:19 gQuigs: imirkin: Is that odd? I would somewhat expect more (or hope for) of an error message
02:19 imirkin: like what... "oooh noooooo!!!! what a world?!"
02:20 imirkin: we submitted commands to the GPU and it does not appear to be executing them
02:21 imirkin: oh, iirc karol had a similar problem
02:21 imirkin: with a hilarious solution... hold on
02:22 imirkin: hmmm... can't find it
02:22 imirkin: but basically GR had to get reset or something
02:22 imirkin: karolherbst: --^
02:22 skeggsb: if it were karol's problem, you'd see more error messages than that
02:23 imirkin: iirc GP107 also had messed up firmware originally
02:23 imirkin: but i would assume that'd be rare
02:23 imirkin: [one would have to have gotten a problem checkout from like 6-12 months ago]
02:25 gQuigs: 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:25 imirkin: gQuigs: right, the proper sequence of commands would wake it up from its deep sleep
02:28 gQuigs: is it failing on commands related to : Console: switching to colour frame buffer device 240x67, or something else? how would I see?
02:29 skeggsb: 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:30 skeggsb: 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:31 gQuigs: understood, will definitely give them a try, thanks :)
11:48 tagr: karolherbst,imirkin, skeggsb: seems like the 406040 error is gone now (Linux 4.16.6, Mesa 18.0.2)
11:48 tagr: no idea what caused it to get fixed, though, but I haven't seen the symptoms in 2 days
12:04 mupuf: tagr: cue the symptoms in 2 seconds
12:04 tagr: mupuf: =)
12:05 PaulePanter: Should Nouveau also accept Option ROMs, which are not a multible of 4 KB?
12:05 PaulePanter: https://review.coreboot.org/#/c/coreboot/+/25999/
12:07 imirkin: tagr: some slight random cahnge in timing? who knows.
12:08 imirkin: PaulePanter: well, the _ROM interface stinks
12:09 imirkin: we just fetch 4K at a time
12:09 imirkin: until we can fetch no more
12:09 PaulePanter: imirkin: Looks like. To support older Linux kernel versions, coreboot needs to be adapted anyway. Just wanted to be sure.
12:10 imirkin: afaik it's not nouveau using the interface weird
12:10 imirkin: it's the interface that's weird
12:10 imirkin: you should be able to find some _ROM implementations in various bugs
12:10 imirkin: we *try* to fetch it all in one go btw
12:10 imirkin: which many ACPI _ROM implementations support
12:10 imirkin: but then we fall back to the slower 4k-at-a-time
12:11 imirkin: PaulePanter: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_acpi.c#L388
12:12 imirkin: len = min(len, (int)obj->buffer.length);
12:12 imirkin: so you should be able to return fewer than 4K bytes
12:12 imirkin: however note that the _ROM isn't quite supposed to be the contents of the option rom
12:12 PaulePanter: imirkin: Can I paste your comments as a review comment?
12:12 imirkin: certainly
12:12 imirkin: the latter ones are the more accurate ones :)
12:13 imirkin: i.e. the ones from *after* i read the code rather than the ones where i was going by memory
12:13 imirkin: this is the code that drives that interface: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
12:14 imirkin: the interface is you return 4K at a time, until you run out, at which point you return a lower length
12:14 imirkin: if you're returning 4K even though you've only filled 1K of data, that's a problem
12:15 imirkin: and also *ideally* you handle any size in the request, not just the interface spec's maximum of 4K
12:16 PaulePanter: Thank you.
12:40 sigod: 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:41 sigod: im using 1.0.15-2
12:50 imirkin: sigod: what kernel / gpu?
12:50 imirkin: sigod: also pastebin xorg log
12:50 sigod: gtx660
12:50 imirkin: oh
12:50 imirkin: are you using blob ctxsw fw?
12:50 sigod: dont think so
12:50 imirkin: have you in the past come in here reporting such an issue?
12:50 imirkin: (your handle seems mildly familiar)
12:51 sigod: maybe but its the first time ive found the error
12:51 imirkin: ok
12:51 imirkin: well, some people with GTX 660's have had trouble with the nouveau ctxsw fw
12:51 sigod: i was asking about hardware acceleration for vpdau the other day
12:51 imirkin: and it seems like some people have had luck with the blob ones
12:52 imirkin: https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
12:52 sigod: SCHED_ERROR 0a [CTXSW_TIMEOUT]
12:52 imirkin: if you extract the firmware frmo 325.25 exactly
12:52 imirkin: then you will also get the various gr fw.
12:52 imirkin: if you move all that into place, and boot with nouveau.config=NvGrUseFW=1 then it should load that fw
12:53 sigod: oh ok
12:53 sigod: thanks
12:56 sigod: so its nvidia creating problems again
12:56 imirkin: mmmm
12:56 imirkin: well in this case solving them :)
12:57 skeggsb: nope, it's us this time, our fw doesn't work properly on some gtx660.. for unknown reason
12:57 imirkin: one could argue that nvidia created the gtx 660 and thus problems, but ... :)
12:58 skeggsb:wishes we could use C to write the ucode
13:00 imirkin: skeggsb: i saw a falcon compiler attempt in one of the envytools repos
13:00 imirkin: dunno how far it had gotten. i think mwk's?
13:00 skeggsb: yeah, iirc mwk was writing one, but stopped :P
13:00 skeggsb: i already tried it
13:00 imirkin: k
13:00 skeggsb: not quite working well enough to be usable
13:01 imirkin: with judicious use of __asm__ perhaps/
13:46 tagr: would it be possible to add a falcon target to LLVM?
13:47 imirkin_: i think it's been tried
13:47 imirkin_: in theory, sure
13:47 imirkin_: but someone who likes llvm a whole lot would have to do it :)
13:48 tagr: there's a few people here that do a lot of work with LLVM, maybe they'll fall in love enough =)
13:49 imirkin_: looks like mwk tried it -- http://0x04.net/~mwk/Falcon.html
13:51 tagr: interesting
13:51 imirkin_: i think that's mostly the spec, but i think he had an impl too
14:18 HdkR: tagr: How much do you love LLVM? :)
14:24 tagr: HdkR: not very much =)
14:25 HdkR: 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:26 HdkR: I've also been writing a couple LLVM backends in the past few months and they are a bit of a time suck
14:33 karolherbst: HdkR: well if you compare to GCC that is ;)
14:34 karolherbst: I think if you don't need all the frontends supported, then it doesn't matter anyway
14:34 karolherbst: but yeah, for the falcons we kind of want to do that with llvm or gcc
14:35 karolherbst: tagr: llvm https://github.com/envytools/llvm/commits/falcon
14:35 karolherbst: clang https://github.com/envytools/clang/commits/falcon
14:35 karolherbst: lld https://github.com/envytools/lld/commits/falcon
14:36 HdkR: Nice
14:36 karolherbst: tagr: but yeah. It would be awesome to have llvm target for falcons
14:36 karolherbst: and it would be nice if nvidia would support/maintain it as well :p
14:37 tagr: karolherbst: yeah, that would be nice, but I don't hold your breath =)
14:37 karolherbst: yeah, I know
14:38 karolherbst: 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:39 HdkR: https://www.youtube.com/watch?v=gg1lISJfJI0
14:40 HdkR: Says it within the first minute :)
14:43 mwk: yeah, I got interrupted before it was usable
14:43 mwk: I suppose I should finish it some day
16:34 sigod: ok i just installed the nouveau-fw package and enabled the kernal module parameter, how do i know if it's working?
16:49 imirkin_: sigod: it should say "using external firmware" on boot or something like that
18:16 nikk_: Hello imirkin, for this task https://trello.com/c/YnhHNblO/100-nv50-nvc0-fix-fbo-blending-formats-glrgb10 we had a few questions.
18:20 adya: 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:25 adya: 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:29 adya: 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:29 imirkin_: i'm confused ...
18:29 imirkin_: so if you look at the NVC0_3D() macro, you'll see that NVC0_3D(foo) will reference NVC0_3D_foo
18:29 imirkin_: i forget where that blend equation stuff is defined
18:30 imirkin_: but all you need to do is say that if it's == DST_ALPHA, then set it to ONE
18:30 adya: 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:31 adya: Is that correct?
18:32 imirkin_: no
18:32 imirkin_: you have to look at the blend settings
18:32 imirkin_: and if the blend settings are s.t. any of the blend functions is DST_ALPHA
18:32 imirkin_: *and* if the RT in question is RGB10X2
18:32 imirkin_: then you should set the blend function to ONE
18:32 imirkin_: this is all a bit tricky
18:33 imirkin_: since currently blend states are in a CSO
18:33 imirkin_: and this would be a fixup on top of such a CSO
18:33 imirkin_: given that this will NEVER happen in practice
18:33 imirkin_: 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:36 adya: 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:37 imirkin_: you should not touch the cso.
18:37 imirkin_: well, maybe add a property to it or something
18:37 imirkin_: which is like "DST_ALPHA used, be careful"
18:37 imirkin_: and then at validate time
18:38 imirkin_: you'd check if FB | BLEND is dirty
18:38 imirkin_: in which case you'd check if any bound fb's are RGBX10
18:38 imirkin_: and if the cso indicates that "careful" bit
18:38 imirkin_: and if so, flip the relevant blend function for the relevant RT to ONE
18:38 imirkin_: and mark the blend state as dirty
18:39 imirkin_: errr ... that second part doesn't have to happen actually
18:39 adya: Oh okay! The bound fb's are the 8 indices of rt right?
18:39 imirkin_: yes, cbuf[i] == rt[i]
18:41 adya: 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:41 nikk_: Thank you imirkin_! We'll get back with the completed task soon!
18:41 imirkin_: cool
18:41 imirkin_: feel free to post partial patches that you think are on the right track
18:41 imirkin_: i can probably glance at them very quickly and given initial reactions
18:41 nikk_: yes okay!
18:42 imirkin_: (post == provide hastebin links to)
18:42 adya: Yes that would be great!
18:42 adya: Yes sure!