12:38 codedmart: I just got a new laptop with a T1000 in it. When I activate my external monitor it turns on but I can't interact with it at all. I can't see the mouse cursor. It is just like a lit up blank screen.
12:43 imirkin: pastebin dmesg + xorg log
14:24 codedmart: imirkin: OK need to finish building a few things for work. Thanks! Didn't know if it was something obvious. But I guess I wasn't very descriptive.
15:07 codedmart: OK here is the output: https://gist.github.com/codedmart/e244193fd45db636bdfe5536c85a5561
15:20 karolherbst: ohh wait.. don't we need acceleration for prime offloading or so? (I never get that one right)
15:21 karolherbst: codedmart: is the laptop running in hybrid or dedicated GPU mode?
15:21 codedmart: karolherbst: hybrid
15:21 karolherbst: but seems like the intel GPU is used
15:22 karolherbst: yeah.. I think not having hw acceleration firmware is causing those issues, but I am only like 50% sure on that
15:22 codedmart: OK let me see
15:23 karolherbst: well, nothing you can do about, because they are not released yet
15:23 karolherbst: _but_ I am not sure if that's the actual issue
15:23 karolherbst: codedmart: output of "ls /sys/class/drm " please
15:25 codedmart: `card0 card0-eDP-1 card1 card1-eDP-2 card1-eDP-3 card1-eDP-4 card1-HDMI-A-1 renderD128 renderD129 ttm version`
15:26 karolherbst: let met check if that might be the issue real quick
15:31 imirkin_: karolherbst: good call. codedmart - sorry, this can't work for now :(
15:32 imirkin_: codedmart: your xorg log is from using nvidia blob driver
15:33 imirkin_: afaik nvidia blob now supports prime offloading of some sort? i dunno the details.
15:33 imirkin_: (for turing+ gpu's, so you're in luck)
15:42 karolherbst: render offloading for all gens
15:42 karolherbst: rtd3 for turing+
15:42 imirkin_: rtd3?
15:42 karolherbst: runtime d3 aka runpm
15:43 imirkin_: what about provider offloading? no right?
15:43 karolherbst: nope
15:43 imirkin_: sad
15:43 karolherbst: well, maybe in the future, who knows
15:48 codedmart: I removed nvidia driver yesterday.
15:49 codedmart: So I need to install the nvidia drivers again then is what you are saying.
15:49 codedmart: nouveau won't work yet?
15:54 karolherbst: codedmart: not really
15:54 karolherbst: it would work in dedicated mode though
15:54 karolherbst: but then battery lifetime...
15:55 codedmart: So for now the proprietary drivers would be better?
15:55 codedmart: Is what I am trying to understand.
15:57 karolherbst: shouldn't make a difference
15:59 codedmart: Oh you are saying I need to use either nvidia or nouveau exclusivly without intel. Dedicated that is?
15:59 karolherbst: yes
15:59 karolherbst: sometimes the firmware has an option for that
16:02 codedmart: Do I need to blacklist the intel for that? I haven't done that.
16:06 karolherbst: bios option
16:06 codedmart: Oh I see what you mean now :)
17:35 lebomart: I do not know how can i get cache storage for variables for reading and writing in sm2.0 spec, i can not remember opengl that well, in vertex shader varyings can be overwritten and read back
17:35 lebomart: but in pixel shader there are occlusion queries and such stuff, i have no idea how they work
17:38 lebomart: maybe depth culling or occlusion queries can do that, but i would like to know how are those writes into depth buffer and framebuffer objects overall cached.
17:40 lebomart: maybe it is possible for instance to mark a framebuffer to read only and cached, and when trying to write into it, one gets an error, however stuff about feedback loops were once studied as well
17:41 lebomart: when you get an error from the interconnect due to memory access not granted, i belive this type of response is delayed, and cache would allready be filled
17:43 lebomart: to make it more comfortable i think the underlying texture object could be also clamped
19:47 codedmart: karolherbst: Any timeline you are aware of to be able to use hybrid?
20:06 imirkin_: it's pending nvidia's release of signed firmware
20:06 imirkin_: so any time between tomorrow and never.
20:12 codedmart: Well it doesn't even work with nvidia proprietary drivers as well. Unless I set to discrete only.
20:26 imirkin_: yeah, can't really speak to the proprietary driver feature roadmap
20:41 imirkin_: moral of the story - next time, buy amd
20:50 endrift: If AMD releases a 2080-killer I may buy one. I'll lose Nvidia GameStream, but I use that approximately never.
20:50 imirkin_: like an ESD device?
20:50 endrift: haha
20:51 imirkin_: i'm sure a bowl of water would most likely do the trick if you want to remain low-tech
20:51 endrift: You know what I mean :P
20:52 imirkin_: :)
20:52 imirkin_: i usually go for alternate interpretations first
20:52 imirkin_: keeps people on their toes
20:55 endrift: imirkin_ more like i'm smirkin'
20:56 imirkin_: frequently.
21:02 codedmart: I thought amd was a pain as well.
21:02 codedmart: Oh well I will see how things go I guess
21:02 imirkin_: multiple gpu's are a pain
21:02 imirkin_: but amd at least has a team working on it
21:03 codedmart: I see
21:03 codedmart: :(
21:04 codedmart: OK thanks! When I tried discrete and nouveau only my screen blurred on boot and I couldn't do anything.
21:06 imirkin_: now _thats_ quality :)
21:06 imirkin_: i guess eDP modesetting needs more testing with turing (i'm guessing it's an eDP panel)
21:06 imirkin_: the original bringup was done on desktop boards, as you might imagine
21:09 codedmart: yup it is an eDP
21:13 imirkin_: if you feel like debugging, perhaps skeggsb can assist
21:21 codedmart: I would be happy to try if it would help the cause.
21:22 imirkin_: skeggsb is based out of AU, so he probably won't be on for a couple of hours
21:56 kisak: g'day, is vaapi expected to work on nouveau's side with a sandybridge/fermi laptop?
21:57 imirkin_: video decoding stuff gets broken intermittently
21:57 imirkin_: but in general, yes
21:57 imirkin_: however i'd strongly recommend using the vaapi support from the sandybridge chip
21:57 imirkin_: it's as good support-wise, and doesn't have any of the nouveau bugs
21:58 imirkin_: otoh if you must use h264 video as a texture input to a tessellation-shader-output thing, then the fermi may have to be it. that seems like a specialty case though.
21:58 kisak: I've got DRI_PRIME=1 LIBVA_DRIVER_NAME=nouveau vainfo to give me mesa 19.1.7 nouveau, but the nvidia chip goes to sleep with smplayer/mplayer
21:58 kisak: vlc is unclear, maybe using gl to render
21:59 kisak: and kodi renders black
21:59 imirkin_: ok ... step 1... does vdpau work?
21:59 imirkin_: (i know, not what you're testing)
22:00 imirkin_: iirc mplayer doesn't support vaapi, but perhaps that's changed?
22:00 kisak: the trouble I'm having with the sandybridge is with vlc/smplayer is that it stalls playback multiple times a minute
22:00 imirkin_: erm, weird =/
22:00 kisak: so I'm trying to see if I have an alternative
22:00 imirkin_: well, mplayer definitely supports vdpau
22:00 imirkin_: which is the thing i'd recommend using
22:01 kisak: I haven't dug up where to explicitly ask for vdpau from nouveau
22:01 imirkin_: should be largely the same
22:01 imirkin_: DRI_PRIME=1 vdpauinfo
22:01 imirkin_: maybe DRI_PRIME=1 VDPAU_DRIVER=nouveau
22:02 imirkin_: mplayer -vo vdpau -vc ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau, <file>
22:02 imirkin_: (see https://nouveau.freedesktop.org/wiki/VideoAcceleration/ for details on how to make that the default)
22:06 kisak: <insert compiling delay as things get rebuilt with vdpau enabled>
22:09 imirkin_: ah sorry, assumed you had it
22:20 kisak: DRI_PRIME=1 VDPAU_DRIVER=nouveau vdpauinfo acts sane
22:24 imirkin_: ok, what about using mplayer then?
22:24 imirkin_: oh ... btw ... are you using DRI2 or DRI3? if DRI2, then offloading requires a compositor.
22:29 kisak: waiting on portage to get to the media players, should be dri3 with xf86-video-intel, which was needed to stop the screen tearing
22:31 kisak: LIBGL_DEBUG=verbose glxinfo | grep -i libgl confirms dri3 is active
22:32 imirkin_: ok just checking
22:36 imirkin_: btw, before you get TOO disappointed, nouveau messed up decoding some h264 videos
22:37 kisak: my expectations are not overinflated, this is tinkering for fun and self-enrichment
22:37 imirkin_: curiously the same videos have problems across all the decoder generations
22:37 imirkin_: including VP2, which is a totally different arch than VP3+
22:37 imirkin_: so ... there must be something about H264 that we don't understand
22:38 imirkin_: (fermi is VP4)
22:38 imirkin_: (or VP5 if it's a GF117/GF119)
22:38 kisak: besides, it'll hate my hi10p h264 content anyway
22:39 imirkin_: and it will express this hate by hanging the gpu
22:39 imirkin_: i haven't gone back and tested any of the "fancy" stuff
22:39 imirkin_: i don't know if the hw is capable
22:41 kisak: it's a GF108
22:41 imirkin_: ah ok. yeah, that was a common pairing with SNB
22:41 imirkin_: it's a race as to which is slower :)
22:41 kisak: indeed
22:41 imirkin_: at least you get GL 4.x on the GF108
22:41 imirkin_: including tess and compute
22:57 kisak: oh good, kodi rendered some interesting vertical bars with vdpau for a twitch commercial before crashing, so it's not completely dead
23:02 imirkin_: heh
23:03 imirkin_: try mplayer?
23:03 imirkin_: GL + video decoding with nouveau = major fail
23:03 imirkin_: and i'm afraid that kodi might try that
23:03 imirkin_: (they're just plain fail on their own, but combined... you can only imagine)
23:07 kisak: okay, mplayer is fine once I threw a less exotic h264 video at it (vdpau)
23:07 kisak: also with ffh264vaapi
23:09 imirkin_: ok cool
23:09 kisak: so now that vdpau is around, things are starting to make sense
23:09 imirkin_: is it a 10bpp video?
23:09 imirkin_: i don't think the hw supports that
23:09 imirkin_: we shouldn't be advertising that profile
23:10 kisak: the less exotic video, normal 8 bit h264
23:12 imirkin_: and that doesn't work with mplayer?
23:22 kisak: thanks for the nudge, I think the framework is healthy, but there's hazards that make it unsuitable for daily use
23:23 kisak: vdpau is more healthy than vaapi
23:24 kisak: this may be the first time I've seen a kernel video driver put death messages in dmesg and not take down the system
23:50 imirkin: kisak: what messages?
23:51 imirkin: the video stuff is kinda by the side, so i think some cases we detect it wedges and can't unwedge it but it also doesn't super-matter
23:53 kisak: tail end of dmesg: http://dpaste.com/07TER68
23:53 imirkin: oh, that's harsh
23:53 imirkin: the VM is stuck
23:53 imirkin: that's pretty fatal if it were your primary gpu