01:01 rhyskidd: moar speed!
08:56 Jukino: HI, I have a GTX 560m video card (NVCF) and writing to pstate file returns me ENOSYS, is there anything I can do to fix that ?
14:58 karolherbst: Jukino: implement reclocking on fermi
15:37 Jukino: Okay, I guess I'll try to learn about nouveau architecture
16:41 imirkin: Jukino: there's some work that was done, but it's incomplete
16:42 imirkin: https://github.com/skeggsb/nouveau/commits/devel-clk
16:43 imirkin: allegedly it was tested specifically on a Quadro 400, but I have a Quadro 400 and it didn't work with mine.
16:59 imirkin: RSpliet: i assume no progress was ever made on G92 and under reclocking?
17:36 RSpliet: imirkin: Sadly no. Over the years I've discovered I only have so much energy for CompSci tasks to spend, and all of that must be channeled to my PhD at this point.
17:37 imirkin: sure. just checking :)
17:52 imirkin: karolherbst: so what's the latest patch you're putting forth to address the start slot thing?
17:52 imirkin: [sorry, i've lost track]
17:52 karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/e1277a762b372c42d022087abbbecd00e0657b77
17:52 imirkin: ok thanks
17:53 imirkin: will have a look in a bit
17:53 karolherbst: thanks
18:05 imirkin: nv50_bind_sampler_states(struct pipe_context *pipe,
18:05 imirkin: enum pipe_shader_type shader, unsigned start,
18:05 imirkin: you need to pass start through
18:05 imirkin: karolherbst: -^
18:05 imirkin: and remove the assert(start == 0)
18:05 imirkin: since i don't think it's the case anymore
18:05 karolherbst: it's the case still
18:06 imirkin: are you sure?
18:06 karolherbst: yeah, all calls have a fixed 0 there, I'll recheck though
18:06 karolherbst: but we could change that nonetheless
18:07 imirkin: no, you're right...
18:08 imirkin: though i wonder why
18:08 imirkin: oh, coz it only keeps track of a max_sampler_seen
18:09 karolherbst: yeah
18:09 imirkin: anyways, it's fine not to pipe it through as long as the assert's are in place
18:09 karolherbst: we might want to assert in nvc0 as well though
18:15 imirkin: karolherbst: can you mail that patch to ML?
18:15 imirkin: none of the ones you've previously mailed were that patch
18:18 karolherbst: imirkin: done. Btw what about your dnz patch, did you push it with my additions?
18:19 imirkin: iirc i did
18:27 imirkin: just going through how num_samplers is used, but i think your patch is correct
19:21 f380cedric: Hi here, I have an issue with video decoding using Nouveau, is it the right place to ask for some helps?
19:21 imirkin: yes.
19:23 f380cedric: Ok, firstly, I have tons of "nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff" in my dmeg, should I care?
19:24 imirkin: DP monitors?
19:24 imirkin: Lyude: --^ no idea what that means
19:25 Lyude: imirkin: the dp aux rpm patches I have on the nouveau mailing list would fix that
19:26 f380cedric: can it affect video decoding in any way?
19:26 Lyude: no
19:27 imirkin: f380cedric: can i guess by your handle that you have a fx380?
19:29 f380cedric: ok, then my problem: I am using a ThinkPad T420, I installed the firmware thanks to https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware, and it worked on F28 until kernel 4.16-17 AFAIR
19:29 f380cedric: imirkin, no I have an HP f380 printer…
19:30 imirkin: ah :)
19:30 imirkin: which GPU is in a T420? (i have a T420s, but it's intel-only)
19:30 imirkin: a GF108 i bet?
19:31 f380cedric: now, I have some issue using my Nvidia for video using DRI_PRIME=1, depending on the command: works, segfault or image corruption (highly stretched, etc.)
19:32 karolherbst: f380cedric: you should probably just use intel for video acceleration though unless you run into problems there
19:32 imirkin: yeah, definitely use intel for video decoding
19:32 imirkin: it's a lot more reliable
19:32 imirkin: that said, i think the issues started happening with the advent of dri3 support in the vdpau state tracker
19:32 karolherbst: don't even know it works prime offloaded at all
19:32 imirkin: used to.
19:32 f380cedric: e.g. using DRI_PRIME=1 mplayer with vo=vdpau vc=ffh264vdpau,ffmpeg12vdpau,ffodivxvdpau,ffwmv3vdpau,ffvc1vdpau,ffhevcvdpau on a mp4 file works well
19:32 karolherbst: ohh, DRI2 only, right?
19:33 imirkin: karolherbst: dri3 support was added. but i had a wide variety of issues, which i liked to blame on dri3.
19:33 imirkin: i never fully tracked them down though
19:33 imirkin: f380cedric: are you a developer?
19:33 karolherbst: f380cedric: thing is, why using the nvidia gpu for that? lower cpu usage?
19:33 karolherbst: or lower total power consumption (allthough I highly doubt that)
19:34 f380cedric: no, I am not.
19:34 f380cedric: Yes, lower cpu usage
19:35 imirkin: the sandybridge intel gpu should handle all your decoding needs
19:35 imirkin: you just have to use va-api
19:36 imirkin: or the vdpau-ontop-of-vaapi
19:36 imirkin: that will work better than nouveau ever has
19:39 f380cedric: if I use mpv --hwdec=vaapi on intel, I have "[vaapi] libva: /usr/lib64/dri/nouveau_drv_video.so init failed"
19:40 karolherbst: weird
19:40 imirkin: f380cedric: pastebin xorg log
19:41 f380cedric: The video will play, but I doubt it is using vaapi
19:41 f380cedric: (regarding the output)
19:41 imirkin: you should be able to tell by looking at your cpu usage
19:42 f380cedric: and if I use mpv --hwdec=vapi --vo=vaapi I get "[vaapi] libva: /usr/lib64/dri/nouveau_drv_video.so init failed [vaapi] Failed to initialize VAAPI: resource allocation failed Error opening/initializing the selected video_out (--vo) device"
19:42 karolherbst: yeah.. it uses nouveau, that's stupid
19:43 karolherbst: f380cedric: what happens if you run with LIBVA_DRIVER_NAME=i965
19:44 karolherbst: and maybe that variable is set to something already by default?
19:44 karolherbst: would be weird though
19:44 f380cedric: same with that var
19:44 karolherbst: is there a i965_drv_video.so inside /usr/lib64/dri/?
19:45 f380cedric: Yes, I set LIBVA_DRIVER_NAME to nouveau by default, I am on wayland, and at that time, it was not able to detect it, had to force
19:45 f380cedric: imirkin, xorg log? I am on Wayland
19:45 karolherbst: detecting nouveau is wrong though
19:45 karolherbst: it should detect i965
19:46 imirkin: f380cedric: oh. well on xorg, the ddx provides a way to tell what the "default" should be
19:46 imirkin: if it doesn't detect intel, that means something's off
19:46 imirkin: complain to the intel folk
19:46 karolherbst: f380cedric: is it even isntalled?
19:47 f380cedric: Ok, now, unsetting LIBVA_DRIVER_NAME and using mpv --hwdec=vaapi, I have "[vaapi] libva: va_getDriverName() failed with unknown libva error,driver_name=(null)"
19:47 imirkin: do you have vaapi-intel-driver installed?
19:48 f380cedric: was expecting it will detect something instead of null
19:48 imirkin: if the driver isn't installed, it won't detect
19:48 f380cedric: karolherbst, yes I have i965 i965_drv_video.so
19:49 imirkin: what if you set that as the LIBVA_DRIVER_NAME?
19:49 f380cedric: set to what?
19:49 imirkin: i965
19:50 f380cedric: no package named vaapi-intel-driver on Fedora
19:50 imirkin: it just looks for ${LIBVA_DRIVER_NAME}_drv_video.so
19:50 f380cedric: [vaapi] libva: /usr/lib64/dri/nouveau_drv_video.so init failed
19:51 imirkin: echo $LIBVA_DRIVER_NAME
19:51 f380cedric: sorry, wrong copy-paste
19:51 f380cedric: [vaapi] libva: /usr/lib64/dri/i965_drv_video.so init failed
19:51 imirkin: ah
19:51 imirkin: and that file is there you said?
19:52 f380cedric: but the file /usr/lib64/dri/i965_drv_video.so exists
19:52 imirkin: what GPU do you have? sandybridge? or ironlake?
19:52 karolherbst: start with LD_DEBUG=libs
19:53 karolherbst: maybe it just fails to load
19:53 imirkin: is it a 2xxx cpu or the gen before that?
19:53 imirkin: (my t420 is snb, but who knows what thinkpad does)
19:53 f380cedric: Intel 2nd Generation Core Processor Family Integrated Graphics driver: i915 (Intel Core i5-2520M)
19:54 imirkin: ok, so sandybridge. should work.
19:54 imirkin: what happens when you run 'vainfo'
19:54 f380cedric: karolherbst, start mvp with LIBVAU… and LID_DEBUG set?
19:54 karolherbst: LD
19:54 karolherbst: but yeah
19:54 f380cedric: libva info: VA-API version 1.3.0
19:54 f380cedric: libva info: va_getDriverName() returns 0
19:54 f380cedric: libva info: User requested driver 'nouveau'
19:54 f380cedric: libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so
19:54 f380cedric: libva info: Found init function __vaDriverInit_1_3
19:54 f380cedric: libva error: /usr/lib64/dri/nouveau_drv_video.so init failed
19:54 f380cedric: libva info: va_openDriver() returns 2
19:54 imirkin: make sure vainfo works ok before you do anything too fancy
19:54 f380cedric: vaInitialize failed with error code 2 (resource allocation failed),exit
19:55 imirkin: and try to get help in an intel channel
19:55 imirkin: not here.
19:55 imirkin: e.g. #intel-gfx
19:57 f380cedric: karolherbst, https://pastebin.com/8k8UrNKa
19:58 f380cedric: and for the nouveau decoding side?
19:58 f380cedric: erase the idea of using my nvidia for video decoding? :3
19:59 karolherbst: it's pointless on hybrid GPU systems
19:59 karolherbst: only valueable thing would be encoding
19:59 karolherbst: but we don't do that anyhow
19:59 karolherbst: or well, if you really need decoding speed it might matter
20:00 karolherbst: but for playback everything is pointless if your main GPU does the trick
20:00 f380cedric: because video decoding eats like between 60-80% cpu, heating my laptop a lot :d
20:00 karolherbst: right
20:00 karolherbst: but it isn't using any GPU
20:00 karolherbst: that's the bug you should fix
20:01 f380cedric: by fixing intel-vaapi you mean?
20:01 karolherbst: yeah
20:01 karolherbst: it might be even be the same bug
20:01 f380cedric: ok, will go in #intel-gfx, thanks: )
21:15 imirkin: karolherbst: are you pushing your patch soon?
21:15 karolherbst: imirkin: will run piglit once just to make sure and push it tomorrow if nothing comes up
21:15 imirkin: k