00:40fredrikh: mareko: yes, but it would be pretty easy to make gl_vertex_array_object dynamically sized
00:41fredrikh: and those aren't shared, so there would be no issues with mixing core and compat contexts
01:31jstultz: so, with FBDEV_EMULATION, it seems FBIO_WAITFORVSYNC isn't implemented.. is that supposed to be implicit in FBIOPAN_DISPLAY or is it just something that can't be emulated properly?
01:32imirkin_: i believe that there's been pushback to implementing it in a "just use kms" style push
01:34jstultz: imirkin_: heh.. i can imagine.
01:34imirkin_: (or you can look at it as "fbdev is deprecated, we don't add features to it", whichever makes you feel better)
01:37jstultz: imirkin_: oh yea.. i get it. i just have a case where it seemed using fbdev used to work well w/o tearing, then something changed and i get lots of tearing... i reworked things to use a kms/drm hwc but the performance there is poor, so i'm trying to understand if the poor performance is due to vsync latency or what.. so i figured i'd try to see if adding vsync waiting to the fbdev case performed similarly poorly or not
01:38imirkin_: i can't help you, but might be good to mention what hw you're on
01:38jstultz: imirkin_: hikey..
01:38imirkin_: erm ... they make display things?
01:38jstultz: imirkin_: kirin is the drm driver
01:39imirkin_: learn something every day
01:39jstultz: imirkin_: its mali on the gpu side..
01:39jstultz: (whah whah)
04:55jstultz: imirkin_: thanks, you mentioning the pushback, made me realize there likely is already a patch.. and sure enough.
04:55jstultz: https://lists.freedesktop.org/archives/dri-devel/2017-February/133021.html 07:13pq: imirkin_, when you think about wth KD_GRAPHICS has to be poked by userspace, maybe it had something to do with the graphics device drivers starting as a purely userspace thing where the kernel did not know at all what going on, it merely allowed userspace to get to the device regs at will. So I'm guessing it was used to prevent the kernel from poking the card while userspace was doing it.
07:25Kayden: huh. the steam client is eating 100% CPU basically all the time, as soon as I launch it...and it's just sitting there displaying the library
07:25Kayden: it even continues eating CPU if I close all the windows so it's just the tray icon
07:26Kayden: I see other repots about this https://github.com/ValveSoftware/steam-for-linux/issues/2954 - and it looks like kisak closed it a few days ago...
07:28Kayden: seems to be pepetually in poll() in vgui2_s.so
08:32aknautiy1: Hello this is Ankit here, I have prepared patches for aspect-ratio support and to add drm client cap, submitted by Shashank Sharma, as a new series https://patchwork.freedesktop.org/series/33984/ 08:32aknautiy1: I had earlier received some suggestions how to go about it, from danvet, ville, daniel stone, and pq, which I have tried to incorporate.
08:34aknautiy1: thanks for the sugestionsguys, and request you to review, if I have missed something.
08:36aknautiy1: I have taken liberty to add a new bit field aspect_ratio_allowed to drm_atomic_state, which is being set if the userspace sets the drm client cap.
08:38danvet: aknautiy1, aspect_ratio_allowd should probably be in drm_mode_config
08:38danvet: without looking at context or anything, also still coffee not really working
08:40aknautiy1: danvet, I had added to drm_atomic_state as state is being sent while setting the drm atomic property
08:41aknautiy1: from which drm_crtc_state is prepared and finally was used, where the umode to mode and mode to umode conversions are taking place
08:42danvet: hm, since it's a client cap you probably need it in drm_file even
08:42danvet: more fun :-)
08:42danvet: since atm you can't get at that one at all from the functions you need it from
08:46aknautiy1: danvet, i have added in drm_file also, and its enough for drm mode_setcrtc path.
08:47aknautiy1: but the problem is, drm_file is not present in the functions where we are actually setting the aspect ratio flags, and the other place where we are reading the flags supplied from user
08:50aknautiy1: danvet, ville in his recent comment mentioned that the filtering of the bits should be done in drm_mode_getblob(). I think that is a place, we can set the bits to be 0 if the aspect ratio client cap is not set
08:51MrCooper: jstultz: as you can see from the discussion of that patch, the main issue is that the fbdev UAPI doesn't allow selecting the CRTC, so the KMS implementation has to pick one somehow, which means you might still get tearing on the display you care about if it doesn't happen to be driven by the picked CRTC
08:52danvet: jstultz, aka stop using the mali blob pls
08:52danvet: or tell arm to have a mode that uses kms
08:55aknautiy1: danvet,ville, Will it be sufficient to just reset the bits in drm_mode_get_blob() ? currently I am taking care of the aspect ratio bits in getcrtc, getconnected_modes (aspect ratio modes pruned if not supported), set_mode_crtc().
08:56danvet: the mode blob is the new atomic way, the other places are for legacy userspace
08:56danvet: we need them all I think
09:00aknautiy1: danvet, yes thats right, the other place where I had made changes is in drm_atomic_set_mode_for_crtc() and drm_atomic_set_mode_prop_for_crtc(). Here is where I am using drm_atomic_state->allow_aspect_ratio to clear the bits if aspect ratio not supported.
09:23pq: aknautiy1, I have not forgotten your weston patch, it's on my todo, but my community time is thin these days.
10:02aknautiy1: pq, I totally understand that, Please take your time. Also, I have tested the weton patches on top of atomi support patches from daniel stone.
10:03aknautiy1: there are minor changes, if required I will send those also.
10:06pq: cool, we'll see what lands first
11:43mlankhorst: keithp: could it be possible you've broken the crtc_id member of page_flip and atomic?
13:15eric_engestrom: in mesa, we have a few specs in docs/specs/; what is the logic behind that?
13:15eric_engestrom: my understanding is that we only kept specs that are not upstream (yet), but I just checked and half of them *are* upstream (now, maybe they weren't at the time)
13:15eric_engestrom: (upstream = khronos)
13:35nha: I really wish games finally went 64 bit, maintaining two separate builds is a pain
14:30imirkin_: jstultz: oh. didn't realize you were looking for an impl :) i probably would have pointed you at that sooner.
15:09vsyrjala: ../lib/igt_vc4.c:42:24: fatal error: vc4_packet.h: No such file or directory
15:09vsyrjala: anholt: ^
15:11vsyrjala: hmm. looks like we don't even have meson options for turning off unwanted stuff
15:38vsyrjala: hmm. oh, looks like the missing vc4 header was just added to igt today
15:40vsyrjala: anholt: problem already solved
15:43mlankhorst: maybe remove the option to skip building vc4 for autofoo?
15:46vsyrjala: dunno. i'd add meson options for amdgpu/intel/nouveau, and change to required:true for the libdrm_whatever
15:46vsyrjala:hates automagic stuff in the build system
15:46vsyrjala: you never know what features you're going to end up with
15:50mlankhorst: vsyrjala: hm, should I also amend the IPS patch to allow 100% of cdclk, instead of rejecting it because IPS can't be enabled?
15:51mlankhorst: and is IPS worth it to force a higher cdclk if it can't enabled otherwise?
15:51vsyrjala: we already allow 100% of cdclk. we just turn off ips if we're past 95%. the patch would break that
15:51mlankhorst: I don't think we currently do...
15:51mlankhorst: intel_crtc_compute_min_cdclk has no check for that
15:52vsyrjala: mlankhorst: no real numbers, but iirc art thought ips+higher cdclk might win over no ips+lower cdclk
15:52vsyrjala: we don't set ips_enabled==true if we're past 95% of max cdclk
15:54mlankhorst: right, my patches messes that up i thinm
15:55vsyrjala: yeah. just moving the max_cdlck check into ips_capable() should restore the current logic i believe
15:58mlankhorst: hm yes
15:59mlankhorst: but still need a separate check for checking against logical cdclk, in theory..
15:59vsyrjala: shouldn't happen. that would mean the cdclk code is buggy and didn't add the extra cdclk headroom
16:00mlankhorst: could be if we decide to inherit in fastboot
16:01vsyrjala: hmm. right
16:02vsyrjala: i think most, if not all, machines boot with max cdclk. but better safe than sorry i guess
16:02vsyrjala: that also means fastboot will waste some power since we won't lower cdclk
16:03vsyrjala: but i guess we'll just have to accept that
16:07mlankhorst: I think in reality it will never happen anyway, f2-hsw-4010u had some sync flags different forcing a modeset, but if I force disabled the modeset it would hang, probably using always on power well for VGA
16:26vsyrjala: we should be turning off vga at readout time
16:27mlankhorst: I think on haswell/broadwell we may also need to check the power well, just in case
16:29vsyrjala: hmm. we check it for the redisable, but not for the initial disable. but we should have init power at that point anyway
16:31vsyrjala: cool. the machine restarted again
16:31vsyrjala: wrong channel for that discssion
16:55imirkin_: nha: note that applications expect the same behavior for queries -- they do a getquery async, and expect it to flush and eventually complete even if they do nothing else.
16:55mareko: libdrm doesn't have a license file, I get emails about what the libdrm license is
16:56imirkin_: MIT or BSD presumably...
19:03nha: imirkin_: my series didn't change the flushing of queries though
19:04nha: at least I don't think so
19:05imirkin_: nha: just pointing out application behavior. no clue about your series or anything else.
19:11nha: sure, thanks :)
19:32yunta: Hello. I have 2 games crashing with mesa 17.3-rc5 and stack similar to https://bugs.freedesktop.org/show_bug.cgi?id=101675 . If I comment on that bug - will anybody notice (CC list looks empty)? Or should I rather raise a new bug?
19:32imirkin_: updates get sent to the assignee and qa contacts
19:33imirkin_: which in this case are dri-devel
19:33imirkin_: that said, if it's a different game, i'd recommend filing a new bug
19:33imirkin_: really easy to mark bugs as duplicates
19:33imirkin_: really hard to tease two unrelated reports apart in a single bug
19:34yunta: oh, ok, I'll do that, thanks
19:35Kayden: ideally one per bug too
19:35Kayden: err, one report per game
19:38yunta: even if stacks are identical right from the mesa entry point?
21:07Lyude: dcbaker: poke, think you'd still have that piglit timeout stuff that you mentioned lying around? think it might end up being useful for something I'm trying to test here
21:15dcbaker: Lyude: let me look
21:20dcbaker: Lyude: https://github.com/dcbaker/piglit submit/timeouts has some untested code to add timeouts to native OpenGL tests (glean, piglit .c files, shader test and glsl parser test)
21:21dcbaker: I know that the timeout mechanism works, but that might be too short for some tests
21:22Lyude: dcbaker: that should be fine, thanks!
21:32dcbaker: Lyude: yw
23:21jstultz: MrCooper: So I'm not hoping to use the fbdev api (trying to move to a drm based hwcomposer), but I wanted to do some comparison to try to isolate performance differences. This isn't for a product, or for upstream.. Just for me, trying to understand how the heaps of old docs and implementations that use fbdev map to the drm implementation I'm working on..
23:22jstultz: danvet: well, for this board i am stuck with mali blobs atm.. but we are working to use the blobs rendering via drm/kms
23:23jstultz: imirkin_: i wasn't far enough along to realize i was looking for an implementation.. just had gotten to the point where i realized the functionality wasn't there, and was trying to figure out if that was because it couldn't be emulated, or if it would be worth trying.. but thanks still, it was helpful!
23:24imirkin_: so did it work out? i.e. were you able to do the comparison you were hoping for?