00:12 imirkin__: emersion: so ... i think this is a wlroots bug
00:12 imirkin__: emersion: it creates a gbm surface with format XR24
00:13 imirkin__: but then chooses a gl config for format AR24
00:14 imirkin__: emersion: have a look at drm.c:drm_connector_set_mode which calls init_drm_plane_surfaces with XRGB8888
00:16 imirkin__: emersion: https://hastebin.com/awiwunojox.php -- this fixes it
00:17 imirkin__: emersion: basically you're saying "my visual is rgba8", but feeding in a rgbx8 surface, and then GL gets confused.
00:17 imirkin__: intel doesn't go through gallium, so perhaps this pans out ok on there. i'd be surprised if it worked as-is with amd gpu's
00:17 imirkin__: perhaps there's some quirk that causes it to still work ok.
00:18 imirkin__: if you can get someone who understands gbm better to say "no, this is how it should work", i can dig deeper into how to make this sort of use-case work.
00:22 rhyskidd: imirkin: so patch for xf86-video-nouveau with wfbScreenInit on the mailing list
00:22 rhyskidd: i'm going to grab something to eat for a little bit
00:23 imirkin__: k
00:59 Comte0: Hi. imirkin, remember https://gitlab.gnome.org/GNOME/mutter/issues/186 ? I have a similar setup and apparently I have no hw acceleration: my desktop works but is very slow
01:00 Comte0: I have similar errors in dmesg
01:01 Comte0: https://pastebin.com/SJ6Pb9Kn
01:07 karolherbst: what a coincidence, I have two G86 GPUs
01:07 karolherbst: or G84?
01:08 Comte0: G94GL & G84GL according to lspci
01:10 Comte0: the gnome bug is from someone with fedora and wayland, I experienced the problem after updating to ubuntu cosmic running Xorg
01:11 karolherbst: Comte0: seems like imirkin said that what the compositor is doing is illegal anyway
01:11 karolherbst: I might be able to talk with somebody about that on a more direct "line"
01:12 Comte0: lspci : https://pastebin.com/ixn6yZkx
01:15 Comte0: dmesg : https://pastebin.com/v370Zd01
01:15 Comte0: Shall I open a nouveau bug, or reply to the gnome one ?
01:16 karolherbst: it depends on whether it makes sense to change the compostior or support that kind of use case within nouveau
01:16 karolherbst: imirkin is probably the best judge for that
01:16 Comte0: ok
01:17 Comte0: thanks for the answer
01:56 imirkin: hm, that's a different method... 0d78 vs 15f0
02:04 HdkR: imirkin: I remember you complaining about point clipping a while back. Do you remember if it is defined by GL spec?
02:04 imirkin: in opposite directions, no less
02:04 imirkin: desktop GL, iirc, clips the center of the point
02:04 airlied: popping points ftw
02:04 imirkin: while GLES clips the rasterized wide point
02:04 imirkin: that's my recollection, at least
02:04 HdkR: oof. That's an annoying spec difference
02:05 imirkin: i'm not sure that this is enforced though
02:05 airlied: don't worry the drivers all do it wrong anyways :-P
02:05 imirkin: so you pretty much get one or the other, dealer's choice.
02:05 HdkR: haha
02:05 imirkin: (maybe even both if you get very lucky)
02:06 HdkR: Depending on side of the viewport it is clipping out of I guess
02:06 HdkR: Points are a mess
02:07 imirkin: you're not a big fan of lines either, iirc
02:07 HdkR: Those 45 degree angles are terrible
02:07 airlied: vulkan also dodges the problem :-P
02:08 airlied: but at least driver can tell the app
02:09 HdkR: There's a reason why Dolphin converts points and lines
02:09 HdkR: Nightmare spec
02:12 imirkin: rhyskidd: i'm still unclear that we need to call the new xf86CursorResetCursor function. i don't see ati calling it anywhere at all.
02:13 imirkin: airlied: you got a quick idea for a reason that dri2 + randr rotation = fine, dri3 + randr rotation = not fine?
02:13 imirkin: could it have to do with the semi-recent HAS_DIRTYTRACKING_DRAWABLE_SRC stuff?
02:14 rhyskidd: imirkin: ati calls it in xf86-video-ati/src/drmmode_display.c
02:14 imirkin: rhyskidd: where? perhaps a later commit, but not in that one
02:14 imirkin: rhyskidd: oh, heh. later commit must have added it
02:15 imirkin: as part of gamma_set. interesting.
02:15 rhyskidd: sorry, yes a later commit
02:15 imirkin: i *have* noticed that cursors don't obey gamma... i wonder if this fixes it.
02:15 rhyskidd: it ends up mirroring amdgpu
02:16 imirkin: right
02:27 imirkin: rhyskidd: ok, those 3 commits pushed
02:59 rhyskidd: thanks
04:03 karolherbst: imirkin: I think the feedback rule involves rendering to the same texture as you read from though
04:03 imirkin: yes.
04:03 imirkin: which is why it doesn't apply here.
04:03 imirkin: this doesn't fix the msaa depth tests btw
04:04 karolherbst: ohh, I see
04:04 imirkin: still struggling with those -- fixed up a minor other bit too, still no joy
04:04 imirkin: sticking in a blanket TEX_CACHE_CTL after we use the 3d engine for blit seems to fix it too, but i think that's just bogus.
04:05 karolherbst: I saw them get fixed by that as well, but... yeah, didn't look into what those tests do
04:06 imirkin: they also get fixed by a giant hammer in nvc0_vbo which is what i had you do iirc
04:06 imirkin: but i prefer logic explanations to problems :)
04:06 karolherbst: :)
04:06 imirkin: logical*
04:07 imirkin: the 2d blit logic seems a lot more problematic
04:07 imirkin: but fixing that up doesn't seem to help =/
04:09 karolherbst: imirkin: I am wondering if we should make it conditional to mark the textures dirty :/
04:09 karolherbst: but I guess there is no easy way to figure that out
04:09 karolherbst: ?
04:09 imirkin: it'll be more expensive to make it conditional
04:10 karolherbst: oh really?
04:10 karolherbst: why though?
04:10 imirkin: just marking it dirty will involve checking all the textures
04:10 imirkin: in order ot make it conditional you ... have to check all the textures :)
04:11 karolherbst: ahh
04:11 imirkin: i mean, there's other trackign options possible
04:11 imirkin: like we could track per resource how it's currently bound, etc
04:11 imirkin: but that's more work
04:11 karolherbst: I never really looked much into the validation code, didn't know it's also doing a lot of things conditionally
04:20 karolherbst: imirkin: btw, any idead who would be best to poke for the copyTexImage validation thing for GLES? I put the patches on a MR in hope somebody would look at them there, who knows about that, but I guess I need to start poking people about it
04:20 imirkin: yeah, dunno
04:20 imirkin: i just look at patches on the mailing list.
04:22 karolherbst: I could send them out to the ML just for you, but I wasn't quite sure if you'd be able to tell that's fundamentally right or have any better suggestions than what we've discussed on IRC already :/
04:23 imirkin: i'm not sure i will either
04:23 imirkin: i just know that i'm not dealing with gitlab's review thing
04:24 imirkin: i'm frustrated enough with the meson situation, i don't need another thing to be frustrated by
04:24 karolherbst: yeah.. I am not a big fan of it in it's current form either. Githubs thing is better imho as you see to which patch a comment/review belongs to
04:25 karolherbst: right, I saw your NACK on the autotools deprecation patch..
04:54 karolherbst: imirkin: by any chance, any ideas for the text issue? Was planning to run the WebGL CTS over the night with all the fixes we came up to see what we might still fail (or chromium)
04:54 imirkin: oh, sorry
04:55 imirkin: a little late to do it "over night" for you, no?
04:55 imirkin: more like "over morning"? :)
04:56 karolherbst: mhhh
04:57 karolherbst: I guess I won't go into the office tomorrow
04:57 karolherbst: but yeah, essentially over the morning then :D
04:57 karolherbst: it's still dark though, so that counts as night
04:59 imirkin: totally untested: https://hastebin.com/ategeciyus.php
04:59 imirkin: (not even compile-tested)
04:59 imirkin: something similar has to be done for compute too
04:59 imirkin: oh crap, and i missed a spot
05:01 imirkin: karolherbst: add this hunk too: https://hastebin.com/uzaposapuz.php
05:01 imirkin: the compute thing requires more thought
05:02 imirkin: it doesn't seem to set a kick handler
05:02 imirkin: i guess we could just stick text into the default kick handler too
05:08 imirkin: karolherbst: let me know if that works at all
05:09 karolherbst: yeah, just booted back with nouveau
05:10 imirkin: there's actually a better way of doing this
05:11 imirkin: only slightly though
05:17 karolherbst: mhh, it seems to work
05:20 imirkin: if the general idea works, i'll redo it in the slightly better way for proper test
05:22 karolherbst: let me try with a lower initial size
05:25 karolherbst: seems like 1 << 14 is the lowest I can go without triggering a resize before running the actual CTS
05:28 karolherbst: mhh
05:29 karolherbst: well, it seems to work better
05:29 karolherbst: survived three evictions now
05:30 karolherbst: there are some tests causing timeouts though
05:30 karolherbst: no idea what that's all about
05:31 karolherbst: and sometimes tests simply take odly long
05:42 karolherbst: imirkin: well, I will let it run now and see if it survives the full CTS run
05:55 imirkin: rhyskidd: having fun? :)
05:55 rhyskidd: mhhhh
05:55 rhyskidd: once i saw something, i kept pulling on that thread ...
05:55 rhyskidd: 17 patches later ...
05:57 rhyskidd: i have looked at HAS_DIRTYTRACKING_DRAWABLE_SRC stuff, but not finished
05:57 rhyskidd: it's a long weekend here, so i have monday as well -- if you don't mind waiting to get a new xf86-video-nouveau released until then?
05:58 imirkin: you know i'm in nyc too, right?
05:58 rhyskidd: probably done for tonight though
05:58 rhyskidd: ah yes, i do think i remember that
05:59 imirkin: so yeah, another day is fine
05:59 rhyskidd: cool
06:52 emersion: imirkin: omg, sorry about that :\
06:53 emersion: yeah, works on intel and amd
06:53 imirkin: no worries. always tempting to blame nouveau.
06:53 emersion: nah, it's clearly our issue
06:53 emersion: i'm really sorry for making you waste time on this
06:54 imirkin: i suspect the other hw drivers don't actually support rendering to rgbx surfaces
06:54 emersion: thanks a lot!
06:54 imirkin: and they just treat it as rgba
06:54 emersion: yeah, that's possible
06:54 imirkin: so you get the alpha value populated in there despite the lies
06:54 imirkin: as an aside... why do you want ARGB in there?
06:56 emersion: hmm, for cursor planes iirc
07:03 imirkin: emersion: ah ok
13:58 karolherbst: imirkin: does the assert "*dstX1 > minValue" mean anything to you? I know there are something blit related we stumbled upon, but that sounds like something else
17:32 imirkin: karolherbst: iirc there was were some issues with float math and large integers
17:32 imirkin: i wrote some patches to upgrade it all to doubles
17:32 imirkin: but that didn't fix everything either
17:34 karolherbst: right
17:34 karolherbst: I hit an assert where the src rect was cliped to (0,0), (0,0) :/
17:35 imirkin: in the end i must have reverted the patch, since i don't see it anywhere
17:35 karolherbst: in the first step scaled to -2,0, then cut due to out of bounds
17:36 imirkin: i ended up not running with asserts iirc :)
17:39 karolherbst: that's cheating :p
17:41 imirkin: that's my favorite thing to do :p
17:41 imirkin: so did my "patch" work out ok? if so, i'll do a real version
17:43 karolherbst: it seems to improve the situation at least. Didn't run into any corruption with it applied, though I am running it on top of my mt fixes to not crash at random points. But running that patch alone helped as well
17:45 imirkin: karolherbst: ok. i'll do a real version that you can test a bit more properly
17:54 karolherbst: cool
17:55 karolherbst: *sigh*, the CTS or GPU thread aborts/crashes for the most annoying reasons
17:55 karolherbst: now it failed to allocated 1.4MB
17:55 karolherbst: :(
18:38 rhyskidd: Lekensteyn: did you have issues with second output screen showing only blank and just the cursor with nouveau xorg ddx since about mid 2017?
18:43 Lekensteyn: rhyskidd: definitely 2018, not sure if 2017
18:43 Lekensteyn: it turned out to be an issue with intel
18:43 rhyskidd: with "Make PixmapDirtyUpdateRec::src a DrawablePtr"?
18:44 Lekensteyn: yes
18:44 Lekensteyn: see https://bugs.freedesktop.org/show_bug.cgi?id=100086
18:44 rhyskidd: cause we think nouveau needs to be updated for the alternative scenario, handing off to a PRIME
18:44 rhyskidd: imirkin and myself have been looking at it this weekend
18:45 Lekensteyn: was it so bad that a rage quite was deserved? :P
18:45 Lekensteyn: quit*
18:45 rhyskidd: trying to find someone with the bug reproducing, so we can test a patche
18:45 rhyskidd: haha, no -- network connectivity
18:45 rhyskidd: ... well not yet, anyway
18:46 imirkin: for me that usually means i tried to delete a word with ^W
19:04 karolherbst: imirkin: \o/ full WebGL CTS run with asserts enabled
19:04 karolherbst: 46/2785 failed tests
19:04 imirkin: yay
19:04 imirkin: make a list?
19:05 imirkin: how did you get past the blitframebuffer assert's?
19:05 karolherbst: crappy hack
19:05 karolherbst: I bound check after clipping
19:05 karolherbst: there are like 8 clips
19:05 karolherbst: and I check between some of them
19:06 karolherbst: I think the logic is entirely flawed
19:06 karolherbst: I just didn't understand it completly to come up with something correct
19:07 karolherbst: the biggest issue is that due to scaling and clipping, you can get 0x0 sized blits and the code doesn't like that at all
19:07 karolherbst: or fails while doing the adjustements
19:11 imirkin: i read through the logic and it seemed correct
19:11 imirkin: but i also had other things to try to fix
19:19 karolherbst: imirkin: " glBlitFramebuffer with src={ (-2,-2), (4, 4) }, dest={ (7,7), (10, 10) } and framebuffers={ (0,0), (8, 8) }. first two clip_right_or_top converts the src to { (-2,-2), (0, 0) } and dest to { (7,7), (8, 8) } ... :/", "and then the src is cliped to { (0,0), (0, 0) }"
19:20 imirkin: i do remember spending a while debugging that logic
19:20 imirkin: it's unfortunate that i didn't keep my various changes
19:20 imirkin: o well
19:20 karolherbst: sad :/
19:20 imirkin: i think i decided "this requires proper investigation, and i don't have time to do it now"
19:20 karolherbst: but at least for htat input it hits an assert
19:20 imirkin: coz all my changes were pretty half-assed
19:23 karolherbst: ohh, we have some feedback loop related fails
19:23 karolherbst: "Feedback loop detection ignores sampled incomplete textures"
19:24 karolherbst: in glDrawArrays
19:27 imirkin: karolherbst: https://github.com/imirkin/mesa/commit/63950e694b478ec0f087662a5003d5b716236457
19:28 imirkin: i _think_ that should be more complete
19:28 imirkin: untested, but compiled :)
19:33 karolherbst: cool, that seems to work as well :)
20:50 pmoreau: Things seems to be working fine with the GM206, nice! So I guess some Pascal regression; I’ll need to look at it later.
20:53 imirkin: karolherbst: let me know if it stands up to some testing
20:54 karolherbst: imirkin: well, it passed through the WebGL at least, guess I will add it to my system wide patches and see how well that works out
20:55 imirkin: k
20:55 imirkin: so ... at the very least, an improvement over the previous thing
20:55 imirkin: should go back and retest with dirty
20:56 imirkin: dirt*
20:56 karolherbst: mhh, something is wrong with GL_ALIASED_POINT_SIZE_RANGE
21:09 imirkin: karolherbst: actually i just realized those pushbuf_space values have to be bumped up a bunch
21:09 imirkin: should be a very minor, rare case
21:16 pmoreau: Grrr, silly me: of course it worked fine, I was on the blob. I was surprised to see a CUDA platform listed with Nouveau --'
21:17 imirkin: hehe
21:23 HdkR: Port AMD's HIP over to Nouveau :P
21:24 pmoreau: Shhhh HdkR
21:25 karolherbst: :O
21:25 karolherbst: imirkin: okay, none of those WebGL fails are anything I'd consider being serious
21:26 karolherbst: halt of those seems to be transform feedback stuff
21:26 karolherbst: others just random stuff
21:27 imirkin: karolherbst: got a list?
21:28 karolherbst: imirkin: https://gist.githubusercontent.com/karolherbst/4ceff9b4a9883b45a4d8c9f2ccdb772c/raw/8d2f3960acf6bf11d3591d6af947843b85937d38/gistfile1.txt
21:29 imirkin: should try to see what's up there... that should def work :)
21:29 karolherbst: sure
21:30 imirkin: oh, i missed a spot with the text thing too
21:31 imirkin: in the blit logic
21:33 HdkR: pmoreau: Just because it's a good idea :P
21:35 pmoreau: :-D
21:41 pmoreau: Fun: of my small memory accesses tests, 5 passes, 6 fails in SPIRV-LLVM-Translator, the remaining 3 failed with various parsing failures in the spirv compiler in Mesa.
21:42 karolherbst: pmoreau: :p
21:42 karolherbst: I probably have patches for all of those
21:42 pmoreau: Where are those? Keeping them for yourself only? :-p
21:43 karolherbst: yeah.. I have like 10 branches in total, some older, some newer
21:43 karolherbst: plan to clean up patches as I run into issues
21:44 pmoreau: I am on your latest nouveau_nir_spirv_opencl_hmm_v3 fwiw
21:44 karolherbst: ohh, yeah... that's not a good one
21:44 karolherbst: use the v2 one
21:44 pmoreau: :o How is the v3 worse than the v2? :-D
21:44 karolherbst: that should have all the fixes needed for pointer stuff
21:44 karolherbst: v3 is newer
21:45 karolherbst: I have to rework the pointer stuff there as it is based on jasons SSBO patches
21:45 karolherbst: which change things
21:45 karolherbst: a lot
21:45 karolherbst: and make a lot of stuff easier as well
21:45 karolherbst: I just made it work to be able to run very basic stuff
21:45 pmoreau: Okay, compiling away
21:46 pmoreau: Did you had a look at the OP_SUB stuff I wrote on your commit? I’m going to check if it’s still an issue or not.
21:47 karolherbst: I saw it
21:47 karolherbst: I basically just copied it from the tgsi path
21:47 karolherbst: but I also disabled loadPropagation at some point
21:48 pmoreau: I see
21:51 pmoreau: Still get two failure inside compiler/spirv, and two segfault (+ the other non-Mesa failures)
21:51 pmoreau: *getting
21:52 karolherbst: pmoreau: so, 10 passes now?
21:52 pmoreau: https://hastebin.com/ewebebucuw.coffeescript
21:53 karolherbst: ohh, such issues
21:54 pmoreau: Nope, still 5 passes only, 6 SPIRV-LLVM-Translator, 2 crash and the 2 in compiler/spirv. (I apparently missed one failure before)
21:56 pmoreau: karolherbst: And here is the stack trace for the segfaults: https://hastebin.com/resicacuxe.shell
21:58 karolherbst: pmoreau: I expect most of the issues to just go away after I rework the pointer support on top of the SSBO rework we've got now. It may just take one or tow days
21:58 pmoreau: Booh, smad and umad aren’t supported yet. :-D
21:59 karolherbst: what? :D
21:59 pmoreau: I’m getting "undhandled opencl opc: 167" and same for 168, from spirv/vtn_opencl.c.
21:59 pmoreau: Oh wait, those are OpLogicalAnd and OpLogicalNot
22:00 karolherbst: :p
22:00 karolherbst: but those should be supported as well, weird
22:00 HdkR: Is there an opcode for 24 bit mul?
22:00 karolherbst: ohh wait, there is really no support for smad/umad yet
22:00 pmoreau: Wait, wrong again, I looked in the SPIR-V spec rather than the OpenCL extented instruction set thing
22:00 karolherbst: HdkR: yes
22:00 HdkR: yay
22:01 karolherbst: pmoreau: meh... should be trivial to add to this patch: https://github.com/karolherbst/mesa/commit/9d3ed0e465814b72e16a05d3065ddc250179b300
22:01 karolherbst: HdkR: why?
22:01 karolherbst: HdkR: it's slower on nv hardware
22:01 pmoreau: Okay, 167 and 168 do correspond to smad and umad for the extended instruction set.
22:02 pmoreau: karolherbst: Don’t worry about them, it can wait. :-) Just running all my small OpenCL tests.
22:03 pmoreau: I’ll have to investigate those SPIRV-LLVM-Translator issues. Probably need a newer version, but they also made the move to LLVM 9 (maybe that hasn’t been merged yet though).
22:03 karolherbst: pmoreau: mhhh, yeah.. I kind of yet to port the structurizing stuff onto master
22:03 karolherbst: there have been some changes making all that stuff we had not compatible
22:04 HdkR: karolherbst: Because I like how silly it is. for historical preservation of course
22:04 karolherbst: HdkR: :D
22:04 HdkR: it shouldnt really shouldnt exist anymore :p
22:04 karolherbst: HdkR: apperantly it's still faster on AMD
22:04 karolherbst: but there is also this weirdo madsp instruction
22:04 karolherbst: on nv
22:04 HdkR: we have what, 2-3 cycle 32bit integer multiplies? really isnt bad
22:05 karolherbst: uhm, I am sure it's not really 2-3 cycles
22:05 karolherbst: at imul needs scheduling read/write barriers and shit
22:05 karolherbst: *at least
22:05 HdkR: depending on what the hardware running the CL kernel anyway :p
22:05 karolherbst: tell me more :p
22:06 HdkR: Oh you know. Intel x86 CPUs
22:06 karolherbst: ahh
22:06 HdkR: :p
23:23 rhyskidd: imirkin: on review, a lot of that extra amdgpu stuff around the drawable patch is because they do dual scanouts and other glamor features
23:23 rhyskidd: which doesn't apply to nouveau
23:29 rhyskidd: something akin to this wip: https://paste.fedoraproject.org/paste/8WU~UJaAyDIo83y6Xm8kNA
23:41 imirkin: rhyskidd: that's basically what i had too
23:41 imirkin: rhyskidd: although i do still have issues with DRI3 + rotation
23:41 rhyskidd: yup
23:42 imirkin: but i have no idea when those started, since i've never tried it before. could go back to the dawn of DRI3 for all i know
23:58 prOMiNd: karolherbst, is there something useful in BIT_MEMORY_PTRS (Version 2) about determining determining memory vendor?