07:57tomeu: got this on a recent mesa, when running piglit within a VM with virgl: void fs_visitor::emit_fb_writes(): Assertion `!prog_data->dual_src_blend || key->nr_color_regions == 1' failed.
07:57tomeu: trying to figure out now which test triggered it
07:59tomeu: (at compiler/brw_fs_visitor.cpp:444: )
08:12Kayden: that's really surprising
08:13Kayden: hmm, something earlier should have prevented that
08:13Kayden: must be testing something illegal
08:14Kayden: (dual source blending with more than one render target isn't allowed, we only advertise 1 for the GL_MAX_...)
08:14tomeu: could very well be a bug in virglrenderer
08:15tomeu: but I guess an error should have been returned earlier?
08:30Kayden: yeah, I'd think so
08:30Kayden: could just be a bug where we forgot to check some case
08:30ntz: hello ... couldn't be error in the header of this paste somehow fixed by some module param ? http://susepaste.org/view/raw/34205353
08:31Adrinael: danvet, I don't see any glib.founds, where are they?
08:31ntz: this drm related error comes very early, even before the xorg stars, it's somehow associated with tty console initialization
08:32danvet: Adrinael, oh, silly me was on an old checkout
08:32danvet: Adrinael, sry about the noise, original r-b looks good again
08:32Adrinael: Ok :)
08:33Adrinael: ivyl, for the record ^
08:34tomeu: Kayden: fwiw, spec/arb_blend_func_extended/arb_blend_func_extended-fbo-extended-blend-pattern_gles2 triggers it, but spec/arb_blend_func_extended/arb_blend_func_extended-fbo-extended-blend-pattern doesn't
08:36tomeu: interestingly enough, the gles3 version passes
08:37Kayden: it works without virgl
08:58tomeu: yeah, pretty sure it's because of virglrenderer
09:08mchauh3: Hi j4ni
09:09mchauh3: Did you get chance to look at https://patchwork.freedesktop.org/series/44823/
11:04mlankhorst: vsyrjala: could we use plane gamma/degamma in the intel ddx somehow?
11:12j4ni: mchauh3: next week. public holiday in .fi
11:20vsyrjala: mlankhorst: not really
11:30mlankhorst: yeah thought it wouldn't have been a good idea :)
13:15mchauh3: j4ni: Thanks!!
13:20interrobangd: ickle, hello
18:22 < GNU\colossus> I use the intel driver for xorg with sna, DRI 3, and TearFree enabled, ant it generally works great. however, when I use a compositor (compton), the last few, er, "rows" if pixels/text in many drawing area (like my terminal emulator) "lag" behind a few seconds when they are supposed to be updated.
18:22 < GNU\colossus> is this known behaviour?
18:22 < GNU\colossus> (I've had it for the longest time - years, probably, and only now had the nerves to ask in here :))
18:23ickle: depends on whether it's the missing sync for glXWaitX in compton or server-side
18:25 < GNU\colossus> ickle, how would I go about finding that out?
18:26ickle: iirc http://paste.debian.net/1030357/
18:26 < GNU\colossus> I can find calls to "glXWaitX" 4 times in compton's sources
18:28 < GNU\colossus> ickle, that's against a file that's part of the intel driver, right?
18:28ickle: compton calls glXWaitX, but mesa doesn't sync against X
18:29ickle: which is one problem, and if it's not that, you have more fun as I don't know what it is
18:31 < GNU\colossus> I'll see if I can get a patched driver built and installed
18:31 < GNU\colossus> thank you very much for your input :)
18:31ickle: (and I may be misremembering the hack to force the flush)
18:32ickle: if you resize windows, there's a fun one where mesa's render target may change size midway through its rendering
18:33dhnkrn: Just curious, how much of an effort would it be to implement TearFree for -modesetting?
18:33ickle: not huge
18:34ickle: don't forget hwcursor support while doing unrestricted frontbuffer sizes
18:35dhnkrn: And why is TearFree not enabled by default on -sna?
18:35ickle: because not everything has "unlimited" GTT
18:36dhnkrn: From what I understand, other OS'es like ChromeOS seem to get away with not doing frontbuffer modifications.
18:36ickle: and anything using a compositor
18:37ickle: it's just the drawing model is 26 years old
18:38dhnkrn: Hmm. Is frontbuffer_invalidate() the easiest way to detect such user spaces?
18:38ickle: the real fun for -modesetting would be removing the 3 different compositing layers inside Xorg into just one talking to hw
18:42dhnkrn: Enabling PSR for user spaces with compositor/-tearfree seems like a tangible step at this point.
18:43ickle: psr + tearfree were meant to be partners in crime
18:43 < GNU\colossus> patch applied and package installed. that was less painful than I had anticipated :)
18:43 < GNU\colossus> I'll reboot and let you know if the operation was a success
18:43 < GNU\colossus> brb
18:45 < GNU\colossus> re
18:46 < GNU\colossus> ickle, afaict, the problem is solved :)
18:47 < GNU\colossus> I realize this might be an ignorant question, but... why isn't that patch in master?
18:47ickle: the bug is in mesa, which was where I was trying to get it fixed
18:48ickle: there's a very very old bug where layers in firefox didn't work due to the same issue
18:49ickle: (lack of glXWaitX, not the lack of preemptive flushing in the xserver)
18:50 < GNU\colossus> ah, I see. but your patch to mesa didn't get merged?
18:51ickle: it didn't, and I did hope with the flow of dri3 patches it wouldn't be an issue any more
18:53 < GNU\colossus> should I file a bug about this somewhere?
18:58ickle: https://bugs.freedesktop.org/show_bug.cgi?id=52930 https://bugs.freedesktop.org/show_bug.cgi?id=90264 https://bugs.freedesktop.org/show_bug.cgi?id=97914
19:04 < GNU\colossus> ickle, I see. do you suppose there's anything I can do/anywhere I can make a scene ;) to get $someone to make this better? or shall I just sit back and wait in fiendish satisfaction, now that I have my own, patched, working-for-me version of the driver?
19:05ickle: I had been meaning to just push that diff
19:06 < GNU\colossus> ah, so you'll apply the workaround in the driver, rather than wait for mesa to fix the underlying problem?
19:09 < GNU\colossus> thanks you very much then :)
19:09 < GNU\colossus> thank*