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