15:01dboyan: hmm, seems that uvm has devastating effects on mmt decoding
15:09karolherbst: dboyan: yes, like everything can change at any time?
15:19dboyan: karolherbst: maybe not that serious. However, some buffers only mapped to CPU via standard ioctls, are mapped to gpu vspace by uvm, and demmt cannot correctly recognize pushbuf and IBs in them
15:21dboyan: I'm trying to hack demmt to at least let them recognize IBs in those traces
15:21dboyan: Decoding command buffer by hand really hurts
15:35dboyan: karolherbst: Do you think the cuInit hang is related to uvm by any chance?
15:37dboyan: All the magic is done by a ioctl named UVM_MAP_EXTERNAL_ALLOCATION, which doesn't exist in 340 series. And cuInit works okay with 340 under mmiotrace
17:05vliaskov: mesa newbie here. Is there a mesa env. variable for outputting TGSI shader assembly when compiling shaders? Similar to INTEL_DEBUG, INTEL_USE_NIR described here: https://blogs.igalia.com/apinheiro/2015/09/14/optimizing-shader-assembly-instruction-on-mesa-using-shader-db/
17:19imirkin: vliaskov: ST_DEBUG=tgsi -- what are you looking for though? that's almost never something that you want...
17:23vliaskov: imirkin thanks. Nothing specific, just want to understand some IR examples. Btw i am browsing for some easy ticket on trello. e.g. is nv_fill_rect https://trello.com/c/Fc6BO64w/151-gm200-nv-fill-rectangle a codegen issue, or should this register be set always?
17:24imirkin: vliaskov: that's a rasterizer thing, so it's just a register setting somewhere
17:24imirkin: i believe i've pointed out what needs to be set as well :)
17:24imirkin: so really what it needs is a piglit test and a very trivial implementation
17:26vliaskov: yes it looks easy (if i can find my way nouveau/mesa internals). I have the piglit test, just need to find where the register setting needs to happen.
17:26imirkin: well, this will be a rasterizer setting, so look in nvc0_state.c::something_rasterizer_something
17:26imirkin: this builds up a command list -- you'll need to emit a command for flipping it between enable and disable
17:31imirkin: vliaskov: so what you need to do is add something in mesa/* somewhere logical to set some bit, then hook it up in st_atom_rasterizer.c, and then process that bit in nvc0_state.c
20:00gouchi: I was wondering if Nvidia Ion (10de:087d) is supported for DRM/KMS ? Because it seems RetroArch can't find drm ressources.
20:00imirkin: should work fine
20:00gouchi: Here is the log https://www.hastebin.com/itutuverek.vbs (lspci,dmesg)
20:02imirkin: gouchi: your logs look perfectly happy... i don't know much about retroarch, but i would GUESS that it needs to run under X?
20:02gouchi: imirkin: we have drm/kms support
20:02gouchi: imirkin: https://github.com/libretro/RetroArch/blob/master/gfx/drivers_context/drm_ctx.c
20:03imirkin: gouchi: are you a retroarch developer?
20:03gouchi: imirkin: no
20:03imirkin: are you a developer? :)
20:03gouchi: imirkin: I have some development but I don't consider myself a developer
20:03gouchi: I have done*
20:04imirkin: does your user have access to /dev/dri/card0 ?
20:04imirkin: and /dev/dri/renderD128
20:04imirkin: [or whatever user is running retroarch]
20:05gouchi: if you confirm it should work in DRM/KMS maybe there is an isssue on RA
20:05imirkin: it should definitely work. in fact it finds the connector with the connected monitor and all its modes
20:05gouchi: but it is the first time I see this error
20:06imirkin: you do have to make sure that you build mesa with egl/drm and gbm support, otherwise the GL bits won't work
20:06gouchi: imirkin: we have
20:06imirkin: also note that with your GPU, you'll only get OpenGL 3.3 and OpenGL ES 3.0 support
20:08imirkin: (and OpenGL 3.0 compatibility context, as with any mesa-based driver)
20:09imirkin: gouchi: looks like https://github.com/libretro/RetroArch/blob/master/gfx/common/drm_common.c#L125 fails
20:10gouchi: imirkin: yes
20:10imirkin: i'm not 100% sure how the DRM api works... you can use the 'modetest' tool, which is available in libdrm sources, to view the full hierarchy
20:10imirkin: i don't know that it's required to have an encoder - not sure.
20:11gouchi: imirkin: thank you very much for the help
20:11gouchi: imirkin: I will check with RA team as it the card should in drm/kms
20:14gouchi: as the card should work* in drm/kms
20:17imirkin: gouchi: actually, no, we do have encoders... e.g.
20:17imirkin: [ 53.817031] [drm:drm_crtc_helper_set_mode] [ENCODER:38:TMDS-38] set [MODE:74: 1920x1080]
20:17imirkin: so i dunno what's wrong with the retroarch code, but i'm pretty sure it's doing something wrong
20:18imirkin: [i always feel bad blaming other people's code esp without serious analysis, so take that with a grain of salt]
20:18gouchi: sure no problem
20:18gouchi: but you confirmed that it should work in DRM/KMS with this card
20:19imirkin: all GPUs supported by nouveau *only* work with KMS
20:19imirkin: (that's Riva TNT and newer GPUs)
21:42dashs: trying out nouveau on stretch debian -- no signal on tv, Xorg.0.log has no EE lines. Where to start.
21:49imirkin: dashs: pastebin xorg log and dmesg
22:03dashs: imirkin: ok
22:05RSpliet: Portal on NVC4 17->74fps
22:05RSpliet: and that's only the middle perf lvl...
22:06imirkin: RSpliet: nice - is that with memory reclocking or just shader core?
22:06RSpliet: imirkin: that's with mem too
22:06imirkin: RSpliet: cool :) are you working on that again?
22:06RSpliet: found a few spare hours tonight
22:07RSpliet: turns out for this card I was about two mistakes away from it functioning
22:07imirkin: RSpliet: imho it'd be worthwhile upstreaming some of your changes
22:08imirkin: even if they're not 100%, it's all behind a pretty big warning anyways
22:08RSpliet: yeah, I agree... it's hard to pick a good moment for that
22:08imirkin: RSpliet: and if you're concerned, you can make NvMemExec=false by default
22:08RSpliet: it is for Fermi as far as I know
22:09imirkin: RSpliet: btw, have you upstreamed "Add support for opcode 0xaf":?
22:09RSpliet: Before I do so though... I recall several Fermi's with even fewer memory training patterns to be uploaded. If I don't make the training routines more forgiving it'd stop nouveau from loading on otherwise fine Fermis
22:10RSpliet: no need according to Ben, script is never executed by nouveau (or so he said)
22:27dashs: imirkin: I don't know how to pastebin an entire file.
22:28imirkin: same way you'd pastebin part of a file?
22:28imirkin: cut & paste :)
22:29dashs: Caan't do moe than one window.
22:29imirkin: why not?
22:30dashs: display will not go down any more.
22:30imirkin: if you're on vt's, switching between vt's will drop the contents of the scroll buffer
22:30imirkin: anyways, you could also upload files to e.g. filebin.ca
22:31dashs: on xterms -- still won't do more than 1 page
22:31imirkin: cat foo
22:31imirkin: then scroll around
22:32imirkin: anyways, i don't really care how you get me the info, but without seeing dmesg + xorg log, i doubt i'll be able to help you.
22:32imirkin: i may not be able to help you in either case, btw. but definitely not without those.
22:36dashs: imirkin: pastebin Stretch.dmesg.xorg has parts of those files...
22:39dashs: imirkin: I pasted what I could to the pastebin named Stretch.dmesg.xorg
22:42imirkin: dashs: ok, and how is your screen connected?
22:42dashs: S-video/component from old GeForce 8400
22:43imirkin: sorry, that was not initially apparent to me
22:43imirkin: unfortunately nouveau doesn't support that on nv50+ :(
22:43imirkin: tv outputs are supported on geforce 5/6/7 series (as well as some earlier chips)
22:43imirkin: but it was never RE'd properly for nv50+ chips =/
22:45dashs: Proprietary drive supports this w/VDPAU on Debian 8 -- wonder if on Debian 9 also?
22:45imirkin: dashs: vdpau should be supported by nouveau
22:46dashs: Ran this hw setup for MythTV with prop. driver, so I it might work here as well?
22:46RSpliet: imirkin:... about that. I'm still quite sure there's problems with MPEG4 decoding on MCP7x. I'm about 500km away from the machine so can unfortunately not do a lot to debug this
22:47imirkin: RSpliet: mpeg4p2 or p10?
22:47imirkin: RSpliet: i.e. "h264" or "mpeg4/divx"?
22:47RSpliet: I think h264
22:48imirkin: hm ok. h264 ought to work, but have the same decoding bugs as all the other gens
22:48imirkin: the divx-style mpeg4 isn't supported on nv98/nvaa/nvac
22:49RSpliet: most apparent with slow zooming shots. Gives complete garble with VDPAU, good picture on sw rendering
22:49imirkin: RSpliet: yeah, it happens.
22:50imirkin: RSpliet: and yeah, super-high-motion scenes is where i've noticed it too (as slow-zooming shots are, in an mpeg sense)
22:50imirkin: i've tried increasing various buffer sizes to no avail
22:52RSpliet: Hah, good, so it's not just me.
22:53imirkin: nope, not just you. there's a note about it on the wiki
23:55dboyan: imirkin: Have you looked at my fp64 branch yet? (or have you had time to do that?)
23:55imirkin: not yet, sorry!
23:55imirkin: still haven't unboxed my desktop
23:55imirkin: i'll probably get to it over the weekend
23:56imirkin: could you send the patches over email? that'll make it easier to review. (and fold/split them in a coherent manner...)
23:57dboyan: okay, i'll try to do that in the weekend, the history on github is somewhat a mess