00:10 jekstrand: mareko: That's a lot of patches. :-)
00:39 mareko: it could be 1 patch ;)
01:18 trowley_: imirkin_, good eye. i-swr was puzzling about that too and we had a conversation with the guy who did that change. unfortunately the details slipped my mind (was distracted by looking up some msaa code) - maybe i-swr can shed some light on it tomorrow
01:21 imirkin: =/
01:37 MrCooper: imirkin: FYI, we currently always fall back to software rendering first, GLX indirect rendering has to be forced with LIBGL_ALWAYS_INDIRECT=1
01:37 imirkin: MrCooper: probably moot as recent X servers disable iglx by default
01:38 MrCooper: right
07:27 danvet: anholt, how much smaller is v3 compared to v2?
07:27 danvet: oh and still ack from me
07:30 danvet: anholt, also ack on patch 1
07:30 MrCooper: anholt: FYI, not all discrete GPUs in laptops physically have display connectors
07:30 danvet: maybe try to get an ack from the fbdev maintainer
07:34 airlied: danvet: see my q last night about missing pull?
08:35 danvet: airlied, hm no?
08:35 danvet: airlied, I did realize that you've pulled it already
08:35 danvet: the one from last week
08:49 vinceab: nashpa: Conversion is done with an hard wired matrix operation with configurable coefficients. The conversion matrix could be bypass. According to the userspace information I would like to be able to program the right YCbCr to RGB conversion matrix (full or narrow range).
08:49 vinceab: nashpa: I don't have details about internal default gamut
09:13 nashpa: vinceab: yeah, you're probably not the only one in this position
10:06 danvet: dvdhrm, evil userspace idea
10:06 danvet: do modesets and drop_master in paralle
10:06 danvet: l
10:06 danvet: what happens?
10:06 danvet: there's nothing afaics that forces synchronization of master status with ongoing modeset operations
10:07 dvdhrm: I sent a patch once.
10:07 dvdhrm: You rejected it ;)
10:07 danvet: stumbled over this since there's also nothing to do the same for fbdev
10:07 danvet: oh really?
10:07 danvet: link?
10:07 dvdhrm: danvet, ooooold.
10:07 dvdhrm: danvet, simple fix: make the master-lock an rw-lock.
10:07 danvet: can I blame this on being young&stupid?
10:07 dvdhrm: Make every ioctl take the read-side.
10:07 dvdhrm: You said it is not worth it.
10:07 dvdhrm: I agreed.
10:07 danvet: ugh, yeah I don't like that
10:08 dvdhrm: Alternative: srcu
10:08 danvet: haha
10:08 dvdhrm: Ends up being the same, though.
10:08 dvdhrm: srcu uses atomics for read-side.
10:08 dvdhrm: So you can just do the rwlock.
10:08 dvdhrm: Same end result.
10:08 dvdhrm: Alternatively, you can make the SetMaster call take the modeset locks.
10:10 dvdhrm: My suggestion: don't use VT switches. Only run a single compositor.
10:10 danvet: dvdhrm, tacking locks in setmaster isn't good enough
10:10 danvet: you might take them after the other thread already checked for master status
10:10 dvdhrm: Because async modeset completion?
10:10 danvet: but before it started taking locks
10:11 danvet: or because of deadlock backoff
10:11 dvdhrm: Ah, I see.
10:11 danvet: nonblocking is entirely hidden from the uapi pov
10:11 dvdhrm: Could check master-status in modeset late.
10:11 danvet: sw status is always synchronous
10:11 dvdhrm: Nice, didn't know that.
10:11 danvet: hm yeah with atomic we could
10:11 dvdhrm: danvet, any reason you want to fix that?
10:11 dvdhrm: Not a real issue, is it?
10:11 danvet: just stumbled over it from an fbdev pov
10:12 dvdhrm: I see.
10:12 danvet: we have random fail in CI, maybe fbdev restore racing with the tests is causing this
10:12 danvet: but didn't check
10:12 danvet: just figured I discuss this with someone with clue first :-)
10:12 dvdhrm: hehe
10:12 danvet: fixing this would involve givine fbdev a real drm_file first
10:12 dvdhrm: There were other issues as well. Like a Page-Flip scheduled, then you VT-switch before it completes.
10:12 danvet: then a real master (but which gets auto-dropped)
10:12 danvet: plus fixing master races
10:12 dvdhrm: The other compositor has no clue the page-flip is scheduled, so any call to drmPageFlip failed.
10:13 danvet: or something like that
10:13 danvet: meh
10:13 danvet: dvdhrm, oh right, that problem
10:13 danvet: I guess, miss a frame at start-up
10:13 dvdhrm: I think Atomic solves it.
10:13 dvdhrm: The missed frame is fine, the error code is the issue.
10:13 dvdhrm: non-obvious to most people
10:13 dvdhrm: So their code aborts...
10:13 dvdhrm: anyway
10:14 dvdhrm: I don't see an easy way to fix the master-issue, other than an rw-lock.
10:15 dvdhrm: Fixing VT+fbdev is all voodoo.
10:15 dvdhrm: The rw-lock would only affect modeset and management calls. The render-ioctls can skip it.
10:15 danvet: yeah, we're not going to have enough goats to sacrifice for that one
10:16 danvet: dvdhrm, anything that needs DRM_MASTER essentially
10:16 dvdhrm: exactly
10:16 danvet: hm, I guess we could do the rwlock
10:16 danvet: and then have another rwlock for fbdev
10:16 danvet: if there's any master, don't do fbdev
10:17 danvet: instead of the current pile of hacks we have in _is_bound
10:17 danvet: but before that we'd need to clean up the fbdev locking I think
10:17 dvdhrm: danvet, semantically fbdev should call SetMaster(), right? And thus fail, if there is an active master.
10:17 danvet: not quite
10:17 danvet: it should be master, but auto-drop if any other master shows up
10:17 danvet: i.e. shadow-master
10:17 dvdhrm: Right.
10:18 dvdhrm: But it also should become Master whenever someone drops master.
10:18 danvet: I think grabbing the read master lock, checking for masters, if yes abort, if not, do something, then only drop the read master lock after it is all complete would be fine
10:18 dvdhrm: So yeah, fallback/shadow-master.
10:18 dvdhrm: Ah, sounds good.
10:18 danvet: atm we have it in lastclose
10:18 dvdhrm: fbdev is one-shot.
10:18 dvdhrm: Does not need continuous Master access.
10:20 danvet: yup
10:21 danvet: well, the next master will set whatever it desires when it becomes master
10:46 danvet: ahajda, you'll follow up with v4 for the exynos deferred fb probe on dri-devel?
10:48 ahajda: danvet: yes
10:56 stark3y: vinceab: to be honest, I don't know when anyone on our side will be able to look at this
12:40 samik: Is glXGetProcAddressEXT() function used to load GLX/GL symbols before GLX 1.3?
12:43 samik: There is a version without suffix that is available in 1.4 and there is an ARB counterpart that's available if the ARB extension is available, should I check for all three?
12:46 samik: There isn't a declaration for EXT version in glx.h and glxext.h, do I need to check for this or the GLX_EXT_get_proc_address extension?
12:48 xexaxo1: samik: I'd use something like epoxy - it handles all the mayhem for you
12:49 samik: Yes, but in case I'm not using it, would that checking be necessary?
12:52 samik: I'm currently checking for the suffixless and ARB-suffixed versions, should I place a check for EXT as well or that won't be necessary?
12:58 Hi-Angel: Why does struct pipe_box have both x,y,z, and width,height,depth? E.g. isn't height is equal to one of x,y,z? (commonly to y, but I've read that some games map height into a different coordinate)
13:12 pq: Hi-Angel, I've no idea what that thing is, but could it be position and size, rather than just size?
13:14 Hi-Angel: pq, ah, silly me, of course, xyz is enough for just a point, so this way we have a cube. Thank you.
13:40 Hi-Angel: Does the boolean r600_texture::is_depth tests whether the texture 3D or 2D?
13:49 Suici: how can i temporaly disable desktop gl support
13:51 Hi-Angel: Suici, do you mean, enable software rendering? You can also set a lower OpenGL version if you want to.
13:51 Suici: not enable software rendering
13:51 Suici: make applications not able to use desktop gl
13:51 Suici: (an application)
13:52 pq: Suici, remove libGL.so is a pretty sure way.
13:52 kisak: make it so that the application can't find libGL.so?
13:52 Suici: kisak , how
13:53 Suici: pq , i dont want to break anything
13:53 pq: rename it - apps that area already running will keep on running
13:53 pq: *are
13:53 Suici: pq , i will not
13:53 Suici: pq , it seems too dangerous
13:53 Suici: pq , xorg runs on opengl ?
13:54 kisak: xorg does not run on opengl, but most DE compositors do
13:54 pq: xorg with glamor does, AFAIU
13:54 Suici: i use whatever is default
13:54 Suici: what is default ?
13:55 pq: depends
13:55 kisak: pq: yes, glamor is X on gl
13:56 pq: In any case, I don't know of any other way.
13:58 Hi-Angel: I'm not sure what you want to, but if you want to make some app to complain that OpenGL not supported, you may try to run the app with MESA_GL_VERSION_OVERRIDE=0 or something similar
13:58 Suici: ok
13:59 Suici: error: invalid value for MESA_GL_VERSION_OVERRIDE: 0
13:59 Suici: Hi-Angel ?
13:59 Hi-Angel: Well, just try some low values, e.g. 0.5, then 1
13:59 Hi-Angel: I don't know what's the lowest number allowed
14:00 Suici: yep it works
14:02 imirkin: i think it really wants %d.%d
14:02 imirkin: so e.g. 0.0 would have been fine too
14:17 robclark: xexaxo1, how crazy of an idea would be moving libdrm_freedreno.so into mesa (ie. built and installed by mesa)? mesa does tend to be the most sophisticated user (esp. if you are using glamor, everything else that uses libdrm_freedreno is mostly some simple test/debug code).. and being able to use mesa's various data structures in libdrm_freedreno would be nice..
14:18 xexaxo1: robclark: seems like a step back, but if you really want to do it I cannot stop you
14:19 robclark: well, I'm probably not likely to do it *soon*.. but every time I have to fix something in libdrm I cry a bit for missing mesa data structures
14:19 xexaxo1: how much [%] of perf increase or LOC reduction are you thinking about
14:19 robclark: I think only downside is mesa is a somewhat bigger dependency
14:19 robclark: more a maintainability thing than anything I think..
14:20 robclark: plus less headache about libdrm version dependency ;-)
14:20 xexaxo1: yes, API design does not always work X months down the line as we think it does
14:20 ickle: I keep wanting drm as an offshoot of the kernel so I can borrow the data structs I'm used to (and not have to reinvent a rbtree)
14:20 xexaxo1: the libdrm "headaches" will be even more confusing
14:23 xexaxo1: robclark: keeping libdrm_freedreno as-is is better since - one finds a bug in it - fix, [you/me/anyone] roll a release with dead trivial procedure at any time
14:24 xexaxo1: then, distros can use the new/fixed libdrm_freedreno with any version of Mesa, regardless how new/old is the latter ;-)
14:24 robclark: that is true.. otoh that kinda locks up the API, so you couldn't make changes that broke backwards compat between mesa<->libdrm_foo (otherwise you'd break other drivers that want new libdrm and old mesa)
14:25 xexaxo1: robclark: rolling stuff in libdrm is cheap
14:25 robclark: there aren't *that* many changes/fixes happening in libdrm_freedreno which is mostly why I tolerate the current state.. I don't have to look at that code much :-P
14:25 robclark: so I don't think that buys you much in practice (rolling new drm release).. it is more likely to be headache than benefit ;-)
14:26 xexaxo1: if you want to do a cleanup -> s/libdrm_freedreno/libdrm_freedreno2/ in the repo + fix the API/ABI on both ends and enjoy
14:26 ajax: or just change the soname
14:26 ajax: that's what they're for
14:27 xexaxo1: not quite
14:27 robclark: yes, that is an approach.. (I don't' really have any major api changes planned.. I managed to pull off the growable-ringbuffer thing keeping backwards compat.. but if libdrm_freedreno was inside mesa at the time I would have changed the API and ended up with some much simpler code ;-))
14:27 xexaxo1: because we have two places that produce modules with unresolved symbols
14:28 xexaxo1: thus, things may build fine, but things will end up with broken
14:28 xexaxo1: libdrm_nouveau did only the soname bump and distros were carrying patches for a while.
14:29 xexaxo1: err too many "things"
14:29 ajax: if you break the abi and the soname, and the next thing you link tries to use a symbol that's no longer there, it will not link
14:30 ajax: this is true even if you don't change the soname, in fact
14:31 xexaxo1: try xf86-video-nouveau e70d801ae9287eab5e82f4d467dc8cd4be1b31a8~1 + libdrm master
14:34 xexaxo1: you can thank me later ;-)
14:34 ajax: nv_type.h:14:28: fatal error: nouveau_device.h: No such file or directory
14:35 ajax: there do seem to be some changes in there where a libdrm_nouveau function grew more parameters, which is again a build error if your cflags are in any way sane
14:37 xexaxo1: iirc the latter wasn't the case for everyone ;-)
14:38 xexaxo1: we even had many patches that "fix" this by adding files and/or changing the API - I don't recall
14:38 xexaxo1: so my suggestion is - do the sed job and get back to more interesting things :-P
14:41 xexaxo1: iirc we did a similar thing with libXfont(2)
15:08 ajax: the difference with libXfont is, while it has multiple consumers, only one of them is something anyone actually works on or cares about
15:08 ajax: so there needed to still be both on the disk
15:09 ajax: libdrm does not have that property
15:10 ajax: had we only changed the abi, xfs would no longer build, let alone link
15:10 ajax: so i'm pretty sure i'm still right and you're still wrong
15:12 xexaxo1: the story of my life - always wrong...
15:12 xexaxo1: everything I say and do
15:13 ajax: well. you might not be wrong, there might have been some other thing about nouveau2 that made it appropriate
15:13 ajax: but me i'm pretty sure about ;)
15:15 xexaxo1: in either case - sed command would take 2 seconds, in the however unlikely case that "I'm right and you're wrong" ... then again let us argue about it ;-P
15:18 robclark: hmm, ralloc could be useful in libdrm too.. anyways, as more drivers use glamor it seems like the usefulness of libdrm being a standalone thing continues to drop.. once you are using glamor, there aren't many things that depend on libdrm_foo but not mesa (and that is probably mostly silly debug/test code used in early bringup ;-))
15:22 ajax: while i might like that to be true there seem to be an awful lot of things linking against it
15:22 ajax: at least to hear repoquery tell it
15:23 ajax: probably a lot of that is unneeded, but like, why does rhythmbox link libdrm
15:23 robclark: heh
15:23 robclark: can you easily subtract out the stuff that also depends on mesa or gbm?
15:25 ajax: most of it?
15:25 ajax: that still doesn't answer why -ldrm is leaking into the link line though
15:25 ajax: which you'd like it not to, so if we ever changed libdrm's soname (cough) we wouldn't have to rebuild 180 things
15:26 xexaxo1: ajax: I think the rhythmbox people might be better suited for that answer ;-)
15:26 ajax: i suspect it's clutter's fault
15:26 ajax: at least, for rb and totem and the like
15:26 robclark: heh, yeah, sounds plausible
15:27 Hi-Angel: I guess "cmask" is "color mask", but what is "fmask" then?
15:28 mareko: fragment mask
15:29 Hi-Angel: Thanks
15:29 hwentlan: danvet, i like ville's idea. not sure if shirish will find time for it, though.
15:35 xexaxo1: ajax: are you looking at ldd or objdump ?
15:36 xexaxo1: *at the output of
15:36 xexaxo1: pretty much nothing from rhythmbox links against libdrm on my Arch system
15:37 jasuarez: xexaxo1, out of curiosity, where you were building Mesa for Android, were you doing as a system component (platform=android) or using the Android.mk?
15:37 ajax: xexaxo1: i'm looking at repoquery --whatrequires 'libdrm.so.2()(64bit)'
15:37 jasuarez: s/where/when
15:38 ajax: which is effectively objdump of the DT_NEEDED entries, but at package granularity
15:39 xexaxo1: ajax: perhaps Fedora needs to start using LDFLAGS="-Wl,--as-needed" ?
15:39 ajax: maybe
15:39 agd5f: anholt, I think actually like 90% of the hybrid laptops we sell have no displays attached to the dGPU. We even make asics without display controllers specifically for those use cases.
15:39 xexaxo1: Arch has been using it for 2+ years and I've been a happy camper
15:40 ajax: fixing the problem in the wrong place tbh but sure
15:40 ajax: the answer seems to be %{_libdir}/rhythmbox/plugins/visualizer/libvisualizer.so
15:41 ajax: (also, last time i checked, libtool actively defeated my attempts to use --as-needed, but i really don't feel like being told libtool isn't broken again so let's not go there)
15:42 xexaxo1: jasuarez: I did something like $ lunch 7; make -j4 clean; make -j4 libGLES_mesa
15:42 xexaxo1: former selects the target - x86 vs arm vs... + selects the drivers to be build
15:43 jasuarez: nice, thank you
15:45 xexaxo1: jasuarez: robh has some patches on the ML for that + skim through his jenkins instance https://ci.linaro.org/job/robher-aosp/lastBuild/parsed_console/
15:46 xexaxo1: it should give you more info that you're looking for
15:47 jasuarez: yes, it does
15:47 jasuarez: seems it builds mesa as part of AOSP
15:49 xexaxo1: yes, you cannot build mesa as a standalone "Android app" - it must be build at system component (ie. part of AOSP)
15:49 xexaxo1: s/at/as/
16:22 syeh: ajax: I need to get a fix into RHEL 7.x, do I need to get the fix into a particular upstream stable first?
16:24 ajax: no
16:24 ajax: i mean, it's nice if you can, but it's by no means required
16:24 syeh: So just attach the fix onto a bugzilla ticket?
16:24 ajax: yes
16:25 syeh: Ok. Ideally, I would like to upstream it so that other distros would just automatically pull it down, but with RHEL, I'm not sure which stable it's pulling out of.
16:53 anholt: agd5f: but this has been done with setups where the protocol screen is a gpu with connectors *and* 3d, right?
17:03 nyef: ajax: Hello. You were recommended to me as someone who might be able to give some advice for adding 3D stereoscopy support in xorg. Is this something that you have the inclination and time to discuss?
17:03 ajax: nyef: sure!
17:07 nyef: Basically, I've almost finished putting together a kernel patch series to enable HDMI 3D output in nouveau (which I'm planning to post for review in about a week), and it seems to me that the next step is to try and get the nouveau X driver to support stereo modes.
17:08 nyef: But it seems like anything in X which ever supported some notion of stereoscopy has been at least deprecated, if not removed entirely.
17:09 ajax: the open source x server has never really supported it, tbh
17:09 nyef: And the video mode selection interfaces don't have any indication of stereo mode support at all.
17:11 ajax: yeah, you'd need to add RR_Stereo as a flag in <X11/extensions/randr.h>
17:11 ajax: and then thread that through the server and client side tools
17:14 fredrikh: the server must also support GLX_EXT_stereo_tree for compositing to work
17:14 nyef: That would cover the modesetting, at least, yes. Might need to get a bit clever to also cover the possibility of 3D Vision Kit support as well (since that basically "just" requires a 100Hz or more refresh rate, an IR emitter, and to swap buffers every frame)...
17:17 Taoki: Hello.
17:17 nyef: fredrikh: Thank you. I presume that this isn't necessary to start with, but would be a very-nice-to-have by the time things are done?
17:18 imirkin_: ajax: fredrikh: do any of you know how this would interact, if at all, with the new-ish multiview stuff
17:18 Taoki: I would like to ask the developers or anyone familiar with the video drivers and x11 to please take a look at the following issue: https://bugzilla.opensuse.org/show_bug.cgi?id=1028575
17:18 Taoki: Since approximately two weeks ago, there is a bug somewhere that causes the system to crash to the login screen inexplicably. Apparently certain windows or panels popping up trigger it, but just now it even happened with desktop effects disabled!
17:19 nyef: The only interfaces that I've found to allow setting stereographic images in the context of X11 are DRI2 (not DRI3) and the "multi buffer" extensions (deprecated in favor of double-buffering, and not implemented in xorg as far as I can tell).
17:19 Taoki: I have a Radeon R7 370 card, which is GCN 1.0 and runs on the RadeonSI driver.
17:19 Taoki: As such it does not use the amdgpu module yet, but still the radeon one.
17:20 Taoki: Are there any known bugs with "radeon", RadeonSI, or GCN 1.0 cards in general, which are associated with what I'm experience?
17:21 Taoki: A brief summary of what happens: All windows and buttons freeze in place, though I can keep moving the mouse pointer around. A few seconds later, the monitor turns itself off (goes into standby) and back on a few times. Then the system either permanently freezes with the screen turned off, or I find myself back to the login manager.
17:21 nyef: So, the list basically looks to be mode-setting for a 3D-capable mode, driver support for maintaining separate left and right images (possibly wranglable with an overlay (underlay?) displayed twice?), support for indirect GL stereo, support for direct GL stereo, and support for non-GL stereo?
17:24 Taoki: Did my messages make it through? My connection mysteriously dropped just while I was typing up on a huge bug I'm having with the driver
17:25 imirkin_: Taoki: check the logs for what's in the channel
17:25 Taoki: imirkin_: My client logs locally
17:26 fredrikh: imirkin_: well stereo_tree is all about the old-style left/right back & front buffers
17:26 anholt: nyef: you may be interested in work keithp is doing for VR, which will allow a DRI client to take over a display output and do its own presentation there without talking to the X server.
17:26 nyef: Is merely having an RR_Stereo flag going to be sufficient, given the range of geometry manipulations involved in some of these stereo modes?
17:26 anholt: I don't see his kernel branch up currently, but I've heard it exists
17:27 nyef: anholt: Possibly for fullscreen, but what about windowed operation?
17:27 fredrikh: imirkin_: maybe a single buffer that's twice as wide as the window can be made to look like two buffers though
17:28 nyef: Taoki: Your client logging locally doesn't affect the publicly available logs, though, and they would tend to reflect what actually reached the channel.
17:29 imirkin_: fredrikh: well, there are (EGL) multiview extensions which allow a winsys fb to have multiple attachments
17:29 Taoki: How do I know what the public logs are though?
17:29 imirkin_: where each attachment is a separate eye (and/or other methods of presenting multiple buffers)
17:29 imirkin_: Taoki: https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel
17:29 imirkin_: [that used to be in topic... i thought. i guess it's long gone]
17:30 Taoki: Oh... thanks. Yeah that's all of my messages
17:31 fredrikh: imirkin_: there's also GL_NV_stereo_view_rendering
17:32 Taoki: Anyway, I vaguely remember imirkin_ and ajax as being deveopers knowing in this sort of thing... might be completely wrong of course. If anyone else knows though, please do let me know what you think and point other devs to this issue! I am really not sure how to find out what's happening and how.
17:36 anholt: nyef: wouldn't help for that. was wondering if you were just doing all this so the client could do things fullscreen.
17:41 nyef: anholt: Not quite. Supporting fullscreen things would be nice, but supporting windowed operation is also important.
18:20 nyef: Having thought about it a bit more, the first critical step is to come up with an xrandr protocol extension and implementation that allows for selecting a stereographic mode, and having it supported in the userland xrandr tool and the corresponding xorg video drivers (probably starting with nouveau, because that's the hardware that I have, and modesetting, so as to provide baseline functionality for DRM drivers with stereo mode support
18:20 nyef: even if they have to disable the accelerated driver to get it).
18:21 agd5f: anholt, right, the protocol screen is usually an intel IGP or amd APU. that said, we have support for hybrid laptops in our pro driver where all rendering is done with the dGPU so that we can deal with the lack of glvnd on enterprise distros
18:21 nyef: Even if it doesn't actually support stereo operation for user programs, it would mean that the overall mode selection works and windowed operation is at least not broken.
18:23 tango_: I'm seeing the oddest of problems and I don't even know where to ask to help on how to debug the issue. the gist of it is that the hdmi output on my laptop is not being assigned a crtc anymore. there is no output in either the framebuffer or X, _but_ I can query the connected monitor EDID and even set the resolution and refresh rate (e.g. with xrandr). this all happened after I started testing an
18:24 tango_: adapter on the displayport connector (which is cloned as HDMI2 on my sistem) and i915 segfaulted. on the next reboot, the actual HDMI output started misbehaving
18:24 tango_: what can I do to produce detailed debugging information and/or where should I actually ask about the issue?
18:24 tango_: (is there a drm-devel or something?)
18:53 airlied: robclark: if you have no second user for libdrm_freedreno it should really be in mesa
18:54 airlied: but in the winsys not a separate lib maybe :-P
18:54 robclark: airlied, well, I do have other users (test code and xf86-video-freedreno.. both of which end users should not use but are convenient in early stages of getting a new gpu working ;-))
18:55 robclark: hence idea of pulling it into mesa but also exporting as a separate lib
18:56 airlied: robclark: you still need to keep abi then
18:57 airlied: but yeah for bringup I suppose having it separate might be useable
18:57 robclark: yeah, that is pretty simple because the other users don't do complicated things so having backwards compat shim is less hard..
18:58 robclark: and this isn't all just about abi, it's also about being able to use ralloc, mesa's hashtable, etc ;-)
19:02 airlied: robclark: just call it libfreedreno :-)
19:03 robclark: libthelibformerlyknownaslibdrm ;-)
19:20 Taoki: Reported my bug from earlier here as well: https://bugs.freedesktop.org/show_bug.cgi?id=100306 Again, if anyone knows what might be wrong, please take a look and let me know what you think.
19:31 nyef: Taoki: So, one HDMI/DPort connector issue, and one X server crash issue?
19:32 Taoki: nyef: No HDMI issues here, I run my monitor on a DVI port. Just the crash
19:32 nyef: Ah, mixing up your case with tango_'s case.
19:35 airlied: Taoki: nothing in anyh logs?
19:36 Taoki: airlied: Which file is that?
19:36 tango_: nyef: yeah, I'm the one with the hdmi issue
19:37 airlied: Taoki: dmesg, journctlctl, Xorg log
19:38 Taoki: airlied: The first two are commands, and I'll post them now. Which Xorg log do I need though? Is it ~/.xsession-errors ?
19:38 airlied: Taoki: not sure where you distro puts it /var/log/Xorg.0.og maybe
19:39 airlied: but after a crash it might be in /var/log/Xorg.0.log.old
19:39 danvet: airlied, https://www.spinics.net/lists/dri-devel/msg136016.html ack?
19:40 danvet: and pls complain if the pull requests still look funny
19:40 danvet:obviously not entirely awake yesterday
19:40 airlied: danvet: nah they are fine, you just confused me enough to pause
19:41 airlied: danvet: ack
19:42 Taoki: journalctl outputs an impossibly large text file...
19:42 Taoki: Guess I'll just pick today from it
19:43 airlied: Taoki: -b for the current boot
19:44 Taoki: Much better :P
19:46 Taoki: Gonna go a bit through these files, and post a bunch of them on the bug trackers
19:59 Taoki: airlied: All relevant logs I can think of are now present on the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=100306
20:03 airlied: Taoki: looks like a gpu lockup
20:03 airlied: and reset fails
20:04 Taoki: airlied: Huh... so it is a GPU freeze after all? Typically when I have these, it's only caused by shaders or games, and the entire system freezes at once (including the mouse pointer).
20:04 Taoki: Definitely goes beyond what I know though.
20:04 airlied: Taoki: the dmesg has some hangs in it
20:05 airlied: might be mesa, might be llvm, llvm 3.9.1 has a regression in it
20:05 airlied: but I'm not sure it can cause that
20:07 Taoki: Wasn't Mesa only for 3D stuff and things that use shaders? Didn't know the system itself used it, except maybe for desktop compositing.
20:08 airlied: Taoki: qt uses it
20:08 Taoki: Aha... would make sense then, I use KDE and everything is qt5
20:11 Taoki: airlied: Is it a known problem, and do other people have it?
20:13 airlied: I haven't seen much reports of it, but I haven't looked
20:16 airlied: Taoki: you might want to ask the llvm packagers to revert r280589
20:17 Taoki: airlied: Should I ask that for the openSUSE staff?
20:18 airlied: Taoki: yup
20:18 Taoki: Will post a comment there about that. Thanks!
20:22 mareko: Taoki: everything uses opengl to draw stuff nowadays
20:22 Taoki: mareko: Good to know. I still had the impression it's mostly games, and the desktop but only for compositing.
20:27 agd5f: Taoki, all "2D" uses glamor which uses OGL
20:28 agd5f: even so, our GPUs haven't had a 2D engine in about 10 years, so you need shaders to draw anything regardless of the API used
20:28 Taoki: Fair enough
20:31 Kayden: robclark: you're pulling libdrm_freedreno into mesa?
20:32 robclark: Kayden, well, it's more of an idle threat for now until the next time I need to debug it.. but the idea does have some appeal (to me at least)
20:32 Kayden: ah
20:34 Kayden: just curious, I've been toying around with pulling a copy of libdrm_intel into mesa as well
20:34 Kayden: found an awesome piglit bug ("bug"?) where every binary was explicitly linked against libdrm_intel, so even if your driver had missing symbols it would still work
20:35 robclark: heh, neat
20:36 robclark: There are a few places where I think ralloc would be useful (like allocating a chain of cmdstream buffers)..
20:36 robclark: and then being able to re-use mesa's hashtable instead of re-inventing it would be nice too
20:37 Kayden: yeah
20:37 Kayden: Chris apparently imported intel/uthash.h for libdrm_intel
20:37 Kayden: it's annoying to have so many different hash tables :/
20:37 airlied: I think you should just write a winsys and ignore libdrm_freedreno maybe
20:38 robclark: mostly as long as it works, I tend to ignore it and forget about how stupid it is to have 12 lists and 5 hashtable implementations ;-)
20:38 airlied: keep the bring up stuff separate
20:39 robclark: that is also a possibility.. although I guess even more bit-rotted stuff by the time I get an a6xx
20:39 Kayden: yeah, if your other users are just for bring up, that probably makes the most sense
20:39 robclark: anyways, mostly theoretical at this point.. I'm probably not going to re-write it just for the fun of it.. but next time I have to deal with it, that might change ;-)
20:44 Hi-Angel: Btw, why quadratic probing patch-set still didn't land? I keep reapply it for local builds.
20:58 jekstrand: Kayden: +1 to hash_table_count--
21:00 Kayden: remote: master docs modified, pushing to https://mesa3d.org
21:00 Kayden: ^^^ so awesome
22:08 robclark: ickle, anholt, btw, I don't suppose you have some trick to unconfuse valgrind about bo cache?
22:09 krh: robclark: you might find something useful here: https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/anv_allocator.c
22:10 ickle: which bit is vg getting confused over? it's generally not knowing the ioctls and mmap
22:10 anholt: my valgrind troubles have been about trying to get it to track my BOs as allocations.
22:11 robclark: right, if screen isn't destroyed, but context is, I still have bo table, and valgrind thinks those things are leaked..
22:11 robclark: looks like I should probably do something like anv_allocator does in libdrm then
22:20 mareko: robclark: why do you need libdrm?
22:24 robclark: mareko, well, originally because of xf86-video-freedreno and also some random debug/test stuff.. these days (other than when I'm still trying to get basic stuff working on a new gpu) modesetting/glamor is the better option so there isn't so much reason for standalond libdrm_freedreno (other than just not re-writing it until I otherwise need to make some big changes)
22:55 jekstrand: airlied: Would it be useful to share a render_pass struct which is just a deep copy of the client one?
22:55 jekstrand: airlied: I'm not sure how well that would work for us but anv_render_pass is fairly close to VkRenderPass
23:02 keithp: anholt: it's on my fd.o repo
23:04 imirkin: keithp: any suggestions for nyef you can share?
23:06 keithp: well, from what I've learned about VR and HMD, you probably don't want a window system driving them directly
23:06 imirkin: the target here are 3D TV's
23:06 keithp: you need something tied in to the IMU and presenting something that the user can reference to avoid making them sick, for instance
23:07 keithp: well, the DRM leasing stuff could be used for that, of course, but only full-screen
23:08 keithp: we used to have 3D GL support for windowed 3D applications, but that's been gone a long time
23:08 keithp: the multibuffer extension had that, and I believe SGI actually used it
23:09 airlied: jekstrand: possibly, we do end up with pretty much the same info, though not sure how well it would work
23:10 jekstrand: airlied: I'm not sure either
23:10 jekstrand: airlied: It just seems like the most sharable thing we have
23:17 imirkin: keithp: so ... would you recommend against enabling this stuff via GLX_STEREO and so on?
23:18 keithp: "it depends"
23:18 keithp: having it integrated into the window system will make it a lot easier to manage as you won't have to write a pile of DRM-specific code, as well as supporting non-DRM drivers
23:19 keithp: however, we don't have any stereo support in the free stack that I know of
23:20 imirkin: well, there's no 3d support of any kind... i think nyef is aware that it'll be a bunch of plumbing
23:24 keithp: yeah, it's all gone these days
23:25 nyef: Just got back from dinner.
23:26 keithp: it's 00:26 here; I need to get some sleep as I'm presenting at 08:50 tomorrow morning
23:26 nyef: GLX_STEREO looks like a good starting point, as far as requesting the capability on the OpenGL side goes, but the only direct rendering stuff that looks plausible is DRI2.
23:27 nyef: GMT+1, huh?
23:28 nyef: I should be awake and possibly paying attention from about... 3 PM tomorrow, your time.
23:28 nyef: Maybe a little earlier.
23:30 nyef: keithp: Sleep well, and good luck with your presentation.