00:01airlied: anyone done a gles31 or 32 cts submission? the docs say cmake <path to openglcts> -DDEQP_TARGET=null -DGLCTS_GTF_TARGET=gles32
00:01airlied: but DEQP_TARGET=null seems to be a crash failing to init egl mess
00:11airlied:goes with x11_egl for now
00:44karolherbst: somebody mind fixing marge? :/
00:44karolherbst: the cannot be merged error kind of happens every time now
00:45karolherbst: well.. maybe not every time but like 50/50 chance
00:46airlied: I think if anyone knew what was wrong they'd have fixed it
00:46airlied: it's also likely a gitlab bug
00:46karolherbst: probably yeah.. :/
00:46karolherbst: maybe some silly race or network or whatever issue
00:47airlied: it might be marge gets an unexpeced return code from gitlab api
00:48karolherbst: would be cool if marge would be more verbose about what's up :D
01:11daniels: karolherbst: scroll up - it's known and documented, but ETIME to fix
01:15daniels: karolherbst: it's relatively straightforward though if you're motivated :) instead of posting a merge command as soon as the CI finishes, it just needs to poll the MR status until it returns 'mergeable'
01:15daniels: just a race condition which we no longer win
01:16gitbot: smarkets issue 263 in marge-bot ""branch cannot be merged" on freedesktop.org" [Open]
01:17daniels: bnieuwenhuizen: https://source.android.com/devices/graphics/sync#sync_timeline no longer mentions swsync :)
01:26airlied: things you learn GLES 3.2 cts runs all the deqp tests
08:42mripard: danvet: is it valid to follow the drm_crtc_state to drm_atomic_state pointer during atomic_enable?
08:42danvet: if you mean drm_crtc->state then I think that will oops
08:42mripard: it looks like drm_atomic_helper_swap_state clears it, so it's not working at the moment, but I can't find a reason why it would be anywhere
08:43danvet: already disconnected from the drm_atomic_state struct
08:43danvet: yeah intentionally doesn't work
08:43danvet: Ideally we'd just pass drm_atomic_state to all these functions
08:43danvet: but that's a design mistake which is fairly hard to correct :-/
08:43danvet: you can chase the old_state though
08:44danvet: not sure about that
08:44mripard: why is that cleared? Doesn't the drm_atomic_state still exist at that point?
08:45danvet: mripard, yeah, like I said design mistake
08:45danvet: the clean way would be to always go from drm_atomic_state
08:45danvet: and never look at drm_foo->state
08:46danvet: hence the entire idea of passing drm_atomic_state around everywhere
08:46danvet: it's somewhat butchered unfortunately
08:48danvet: commit accessing these ->state pointers is a bit awkward so imo best to move away from them
08:48mripard: yeah, I was trying to get the connector state from an encoder
08:48mripard: so through the encoder crtc state, and iterating over all the connectors in that state
08:49danvet: that one is easy
08:49mripard: but I guess the proper way to fix that would be to convert to the bridge API and use a bridge_state
08:49danvet: ah no you said enable
08:49danvet: well use atomic_enable
08:49danvet: it is all there already for you
08:50danvet: ideally we'd convert all atomic commit callbacks to that pattern
08:50danvet: atomic_do_something(drm_foo *obj, drm_atomic_state *state)
08:51mripard: sorry, I meant the encoder's enable, not atomic_enable
08:51mripard: and that one just has a pointer to the encodre
08:52danvet: that's the function you want
08:52mripard: I missed that one somehowe
08:52mripard: thanks :)
08:53danvet: but yeah if you spot this anywhere else, the parameter pattern used there is what I think we wanted everywhere
08:53danvet: except historical accidents and all that
08:53danvet: vsyrjala, ^^ should we do a todo.rst entry for this maybe?
11:46vsyrjala: danvet: i guess a todo might encourage people to work towards it
11:48vsyrjala: one semi-related thing i was trying recently was to add another for_each_foo_in_state() variant that has neither old or new state pointers. but iirc couldn't get cocci to understand our preprocessor magic so didn't really get anywhere :(
12:08mlankhorst: that could be useful. :p
12:12danvet: vsyrjala, you're going to type a quick patch?
12:12danvet: I think you have the clearest idea on how this should all look like ideally
12:14danvet: https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#atomic-modeset-helper-functions-reference <- maybe we even want to put it in there instead of only hiding it in todo.rst
12:55vsyrjala: danvet: https://paste.debian.net/1156794/ ?
12:56danvet: vsyrjala, maybe add that drivers should also stop directly accessing drm_foo->state pointers in their commit functions
12:56danvet: I think conceptually that fits in there
12:56danvet: maybe make it specific like your example, so drm_plane->state
12:57danvet: with that added, rb: me
13:09vsyrjala: https://paste.debian.net/1156801/ clear enough?
13:09vsyrjala:has tunnel vision when it comes to this stuff
13:11danvet: vsyrjala, lgtm
13:19vsyrjala: and naturally my sphinx is broken somehow
13:30vsyrjala: looks like some kind of known incompatibility with sphinx3
13:31vsyrjala:hacks around it
15:28mripard: anholt__: did you receive my HDMI series last week?
15:51imirkin: daniels: is cgit.fd.o having trouble? appears to be timing out.
16:35anholt__: mripard: I've been on vacation for a week. You really need to get dave stevenson and company engaged in review, though.
16:38alyssa: what's the process for proposing release notes? (for 20.2 in our case)
16:39imirkin: none, afaik
16:39kisak: alyssa: new features? I think it's in https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/docs/relnotes/new_features.txt
16:40alyssa: kisak: Snazzy, thanks :+1:
16:40imirkin: the release manager generally throws in a few words of their own too
16:40imirkin: and it's just stuff they feel like saying
16:41alyssa: (GLES3.0 on Panfrost, as in by default no debug flags and passing 99.9% of deqp-gles3)
16:42alyssa: thanks :)
16:42imirkin: the last bits become increasinly annoying
16:42alyssa: all the big ticket items were there but yeah long tail of annoying fails
16:42imirkin: as you fix the low-hanging fruit, only the high-hanging fruit remains :)
16:42alyssa: blit.nearest_consistency.* seems like voodoo
16:42imirkin: useful to bring a giraffe
16:42alyssa: dsuhigrshgslig nice :P
16:42alyssa: seeing as v3d has a hack in u_blitter for it
16:43imirkin: yeah, blit can be a bit ridiculous
16:43imirkin: you can give it highly annoying parameters
16:43imirkin: which defy logic but are still supposed to work
16:43imirkin: iirc there are some core bugs in there too
16:44imirkin: last i looked into it, at least, as exposed by the webgl test suite
16:44imirkin: the blit info only takes 16-bit size args ... or it uses pipe_box or whatever
16:44imirkin: but the blit args can be > than that, and even if your fb size is smaller, it can matter
16:44alyssa: ruh roh
16:46imirkin: double-checking which ones those were so i can point you to them in case you're interested
16:48alyssa: uh, am I better off not knowing? ;P
16:48imirkin: one has to carefully understand what the args to glBlitFramebuffer are
16:48imirkin: and how they have nothing to do with framebuffer coordinates
16:48imirkin: contrary to what one might think
16:49imirkin: or how they documentation might read :)
16:49imirkin: hrmph. can't find it. or the fail got fixed.
16:50imirkin: i did try to fix a bunch of it...
16:51imirkin: i didn't leave comments on how this can happen, but my "fix" for it was 9bf0614116cdfdbfca9952c6547331731a462dcc
16:51imirkin: aka a huge cop-out
16:53alyssa: this seems.. concerning
16:56imirkin: i did try fixing it in st/mesa, but it was more involved than i was willing to do at the time
16:56imirkin: where my goal was to put together a strong webgl conformance submission to the chrome team to reinstate nouveau
16:57imirkin: but i eventually realized it was too high a bar, and they'd come up with additional issues anyway
16:57alyssa:flipped on chromium with the gles3 changes as well... here's hoping things are stable
16:58imirkin: it's the standard thing... "it works on nvidia, therefore nouveau must be broken"
16:58imirkin: i dunno if the ARM driver is generally high quality, but it's a pretty common thing with nouveau.
16:58Lyude: imirkin: i think the point we get ci is probably the point we can start pushing chrome to enable hardware gl
16:59alyssa: imirkin: I guess part of it is that not a lot of people will be using panfrost and not know it and have normal well configured systems at this point
16:59alyssa: whereas nouveau will end up on a lot more, uh, normal systems
17:00imirkin: Lyude: i don't think they will ever re-enable -- since they've disabled, they don't know what issues may lurk, and the spectre of those issues will encourage them to just "keep it safe"
17:01Lyude: imirkin: at a point where we get ci i'd be happy to talk to fedora about just enabling nouveau in our chromium builds to make that a harder point for them to use :)
17:01karolherbst: Lyude: ohh.. good idea actually
17:02karolherbst: but I think chromium does threaded GL or not?
17:02karolherbst: this is a huge pain until it's fixed
17:02imirkin: karolherbst: i have it enabled. works fine.
17:02Lyude: karolherbst: well, i should also imply "at a point where we have ci and more reliable conformance, enough so we'd trust random folks to run chromium on it without issues"
17:02imirkin: people were complaining about black boxes, which i also see on rare occasion
17:02karolherbst: Lyude: right
17:03karolherbst: Lyude: I try to finally work on the nouveau CI stuff, just need to move the rest of random stuff out of the way I have to deal with :D
17:03Lyude: karolherbst: whatever the solution is maybe it'd help for us to see if we can get the google chrome folks to tell us what would make them reconsider something like that, and whether they'd want that kind of help with testing
17:03karolherbst: might even get to it this weekend
17:04Lyude: karolherbst: remember i've still got those igt patches waiting on the ml that we need for igt to work w/ nouveau ;)
17:04Lyude: also, I pushed crc support last night
17:04karolherbst: Lyude: right.. at this point I only care about userspace testing though
17:05Lyude: imirkin: also, I'd imagine there's chromeos folks here who might be able to help push that discussion forward once we reach the point we'd be comfortable in having them try again
17:05karolherbst: imirkin: would be interesting to figure out what is causing those black boxes though
17:05imirkin: karolherbst: yeah, that'd be interesting. happens very rarely.
17:06imirkin: i believe there were some issues earlier where the default uniform buffer would get "messed up" on maxwell+
17:06karolherbst: imirkin: maybe we just need to enable some workarounds which are enabled for intel as well :D
17:06imirkin: but pendingchaos fixed it a long while back
17:06karolherbst: there is a driver bug workaround called "clear_uniforms_before_first_program_use"
17:06karolherbst: is that one enabled for you?
17:07imirkin: karolherbst: https://hastebin.com/raw/yucanaxale
17:07imirkin: (yes it is)
17:08karolherbst: mhh, looks close enough to what I've got here
17:20alyssa:running webgl cts
17:20alyssa: getting fails on trig functions?
17:20karolherbst: alyssa: clone it first and run it locally to skip networking issues ;p
17:20alyssa: (maybe not enough precision in the mesa lowering?)
17:21alyssa: karolherbst: That would have been wise, too late ;p
17:22imirkin: alyssa: note that there's both webgl1 and webgl2
17:22imirkin: webgl1 is like GLES1, webgl2 is like GLES2
17:22alyssa: GLES2 vs GLES3 methought
17:22imirkin: GLES3 and GLES2 are basically the same
17:22imirkin: just more features
17:23imirkin: whereas GLES1 is fixed function
17:23imirkin: i could be off. that's my recollection though.
17:23alyssa: iirc webgl1 = GLES2
17:23imirkin: ah no - looks like you're right
17:23alyssa: webgl2 = GLES3
17:23imirkin: and more extensible
17:24alyssa: chromium refuses to do webgl2 on desktop GL < 3.3 so this is only webgl1 unless you force --use-gl=egl or don't build panfrost desktop
17:26imirkin: yeah, ES3 actually requires some stuff not even in GL 3.3 :)
17:26imirkin: like annoying xfb things
17:27imirkin: pause/resume, probably a few others
17:27alyssa: yeah, but it doesn't use the es3 context even though it's there
17:29alyssa: which tbh is fine for now, webgl1 conformance is hard enough :)
17:34tomeu: doesn't it require some robustness stuff that we certainly don't have implemented in panfrost?
17:34alyssa: tomeu: it ought to
17:34alyssa: somehow it doesn't..
17:38anholt__: generally, webgl impls do all the robustness stuff in shader translation and their own state tracking.
17:38anholt__: (buffer access wise)
17:38alyssa: we're not advertising SSBO support yet at any rate
17:39imirkin: UBO still matters
17:40imirkin: but i don't think there's anything you can do in state tracking to prevent an index buffer out of bounds access to a vbo
17:40alyssa: UBO's hw bounds checked for us
17:40alyssa: for shader access
17:56alyssa: oh hey, webgl cts exposing Real compiler bugs
17:56alyssa: I like
17:57imirkin: any time you run a new testsuite, you expose a bunch of new issues
17:58alyssa: one of the shaders is spilling horribly
17:58alyssa: I could try to debug the spill code or I could figure out why it's spilling horribly
17:58alyssa: I should probably fix both :>
17:59imirkin: spilling sucks.
17:59imirkin: how many registers do you have (in 32-bit units)?
17:59alyssa: at 1/4 occupancy
18:00alyssa: 32 at 1/2, 16 at full
18:00alyssa: (but it's 128-bit units because vector)
18:00alyssa: shader121 - MESA_SHADER_FRAGMENT shader: 635 inst, 482 bundles, 214 quadwords, 16 registers, 1 threads, 0 loops, 115:232 spills:fills
18:00alyssa: This will be fun.
18:02imirkin: 64 * 4 - that's a good number of registers
18:02imirkin: but if you want to test spilling, just go to shadertoy.com
18:02alyssa: er, no, 16*4
18:02alyssa: well, (64 * 4) bytes
18:03imirkin: oh ouch
18:03imirkin: 64 32-bit values per lane? that's spilling central
18:03imirkin: that's what fermi/kepler1 have
18:03imirkin: lane = "invocation"
18:03imirkin: or "thread"
18:03alyssa: yeah :c
18:03imirkin: or whatever you want to call it
18:04imirkin: 64 is not enough. need maor. tesla had 128, fermi/kepler1 have 64, then kepler2 bumped it up to 256 and all was well.
18:04imirkin: but yeah - the real compiler test is shadertoy
18:05alyssa: okay thi sis definitely a bug
18:05imirkin: e.g. https://www.shadertoy.com/view/4sf3Dj
18:05imirkin: among many others
18:05alyssa: I don't dare click
18:06imirkin: prepare a fire extinguisher first
18:06alyssa: clicked anyway, 5fps but runs!
18:06imirkin: does it show the right thing?
18:06imirkin: (the nintendo gamecube logo animation)
18:06alyssa: yeah :)
18:07imirkin: that means _something_ is working
18:08alyssa: imirkin: Surprisingly, no spills there
18:08alyssa: shader110 - MESA_SHADER_FRAGMENT shader: 3497 inst, 1114 bundles, 2792 quadwords, 12 registers, 1 threads, 2 loops, 0:0 spills:fills
18:08alyssa: (48 scalar registers)
18:09imirkin: i just remember i had some kind of bug with that one
18:09imirkin: forget what it was by now, but on some gens the cube would be randomly off-center
18:11alyssa: ^^ what I'm up against no
18:11imirkin: i get about 4fps with this one - https://www.shadertoy.com/view/4tByz3 - so you know it's good
18:11imirkin: (the gamecube one i got like 50fps)
18:11alyssa: definitely not clicking
18:12imirkin: famous last words
18:13alyssa: Somehow if I set fp16, the spilling gets worse. uh
18:13karolherbst: completly unrelated, but if a webgl website makes your system not repsond, because it's overloaded, is that worhty of an CVE? :p
18:13alyssa: karolherbst: webgl is the bug =p
18:15glynnc: is this a suitable place to ask about mesa/libglvnd?
18:15glynnc: since my latest gentoo upgrade, I can't connect to a remote X server
18:16glynnc: I'm guessing because it doesn't support the extension?
18:16glynnc: is there something like LIBGL_ALWAYS_INDIRECT?
18:16glynnc: to say "just talk GLX to the specified display"
18:16alyssa: imirkin: Okay, if I enable FP16 and force chrome to use gles, the spilling disappears and the test passes. So it's definitely a bug in the spill routines.
18:16alyssa: I'm starting to question my life choices ;)
18:22austriancoder: anholt__: is anything missing for !5661 ? Was not really sure about the CI docs
18:23imirkin: alyssa: yes, a common thought when one starts to debug spilling issues.
18:24anholt__: austriancoder: I meant adding "how do I set up the environment= for the runner" in the Setup section
18:24anholt__: (I took some guesses as to what you wanted and I was right, but let's just document it
18:24imirkin: glynnc: indirect GLX (aka iglx) has been disabled by default for a while
18:24glynnc: in the client library?
18:24imirkin: no, on the server
18:25imirkin: you have to make sure to start it with +iglx
18:25imirkin: or the equivalent xorg.conf setting
18:25glynnc: the server is Cygwin's Xwin.exe
18:25imirkin: (don't ask me what it is)
18:25austriancoder: anholt__: okay
18:25glynnc: and it was working fine until the client upgrade
18:25imirkin: and is the client running on linux and connecting remotely?
18:25imirkin: afaik that _should_ continue to work
18:26glynnc: but now I just get "Error: couldn't find RGB GLX visual or fbconfig"
18:26imirkin: glynnc: pastebin glxinfo?
18:26glynnc: that's practically the entire output from glxinfo
18:26glynnc: the other line is: "name of display: w7:0"
18:26glynnc: it's not getting as far as connecting
18:27imirkin: do you know what the old/new versions of mesa are?
18:27glynnc: from what I've read, libglvnd tries to use a (recent) extension to find out where to dispatch to
18:27imirkin: oh right - gentoo enable libglvnd by default
18:27glynnc: 18.3.6 => 20.0.8
18:27imirkin: you can disable it by adding -libglvnd
18:27glynnc: so just rebuild without it?
18:27imirkin: unfortunately it'll have wider-ranging implications than just mesa
18:28glynnc: there's no way to make libglvnd talk to a "generic" X server
18:28imirkin: i don't know much about libglvnd myself though - sorry
18:28imirkin: i just know how to disable it :)
18:29glynnc: is it just a workaround for nvidia not using the standard X.org driver interfaces?
18:29imirkin: more of a workaround for having multiple libGL providers at once
18:29glynnc: wasn't that just a) nvidia and b) everyone else
18:30glynnc: normally the standard (mesa) libgl would talk to the driver or speak GLX
18:30glynnc: but nvidia insisted on providing their own libGL as well
18:30imirkin: and AMD
18:30glynnc: oh, them too
18:31vsyrjala: that ladybug is "nice". very slow, and gpu hang on cfl when going fullscreen. ivb was ok
18:31glynnc: well, this system basically uses a) GLX, b) Xvnc, and c) intel integrated, in that order of priority
18:31glynnc: so I'll just rebuild without it
18:31imirkin: gentoo used to have eselect-opengl which would globally switch
18:32imirkin: but that doesn't account for intel + nvidia hybrid
18:32imirkin: where you want to use blob for nvidia and mesa for intel
18:32imirkin: fwiw i've just added -libglvnd into my global use flags
18:32glynnc: yeah, if I use -libglvnd for both mesa and xorg-server, it unmerges libglvnd and merges eselect-opengl
18:32imirkin: since i don't require the additional complication
18:34glynnc: I did encounter this: https://github.com/NVIDIA/libglvnd/commit/a77ce91f37d05e98725a277b0b5cd015b61ac0d5
18:34glynnc: which suggests they added an env var, but no clue how to use it
18:35imirkin: i think it's to force one or another library for a particular GLX thing
18:37glynnc: well, I'm just rebuilding without it, see how that goes
18:41danvet: karolherbst, we still don't have anything like cgroups for gpus
18:41danvet: and I think someone actually did file a cve about that, and it's unfixed for years or so
18:44karolherbst: danvet: maybe somebody should :p
18:44danvet: well it's kinda hard
18:44karolherbst: managed to freeze my entire desktop with that webpage
18:45karolherbst: what's hard about it?
18:45danvet: many gpus you can just implement an endless loop, and all that can be done is freeze everything for 10s and then reset
18:45karolherbst: I claim websites can DOS your system :p
18:45karolherbst: danvet: doesn't matter for filing an CVE :p
18:45karolherbst: it's not fixed
18:45danvet: oh you mean filing the cve
18:45karolherbst: by desktop froze
18:45danvet: yeah that's the easy part :-)
18:45karolherbst: gives more motivation for fixing it :p
18:47imirkin: vsyrjala: yeah, shadertoy is a quick way to hang pretty much anything
18:47imirkin: and also a great intro to how *not* to GPU rendering :)
18:49alyssa: can confirm
18:54pendingchaos: can someone review this nir_lower_int64 patch: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5709 ?
19:39ajax: why do we bother having two code paths for createcontext
19:39ajax: why do we not promote everything to createcontextattribs and move the hell on
19:39imirkin: that way they can have different bugs
19:42ajax: i guess GLX_ARB_create_context is only eight years old
19:42ajax: we're not allowed to do anything reasonable until at least a decade has passed right
19:42ajax: (to be clear this is about the internal API into the DRI driver)
19:42karolherbst: ajax: write patches?
19:43ajax: don't threaten me with a good time
19:43karolherbst: but I guess there could be a stupid issues foiling this plan
19:44ajax: the issue would be you might try to load a DRI driver from mesa 8.0 and expect it to work, i guess
19:45imirkin: ajax: more like 7.11 or whatever that version was when dri1 went away
19:45karolherbst: what's the point of allowing drivers from older mesa versions to load anyway?
19:45imirkin: that's how we can still support loading those drivers that got removed
19:45ajax: developer convenience, primarily?
19:45imirkin: with the new libGL
19:46karolherbst: ohh, I see
19:46ajax: in rhel6 we had to invent a mesa-dri1-drivers package at one point because 8.0 dropped the DRI1 drivers
19:46ajax: not, we hope, that anyone was _using_ a matrox g550 with rhel6, but we shipped it so we had to support it
19:47karolherbst: oh well
19:47ajax: and every time i threaten to delete the rest of the memory of dri1 i get someone saying rage128 still works just as well as it ever did
19:48karolherbst: which driver does support rage128 though?
19:48karolherbst: not the radeon one?
19:48ajax: (meaning it still doesn't support both gpus of the rage fury maxx, shakes fist)
19:48ajax: right, not radeon. r128.
19:48karolherbst: meant the mesa driver though
19:48ajax: despite that r128 is basically the radeon zero-hundred
19:48karolherbst: or was there a r128 mesa driver at some point?
19:49imirkin: there was a dri1 driver
19:49ajax: it was named r128, yes. it went away from mesa after 7.11
19:49imirkin: that never made the dri2 transition
19:49danvet: I still have a i810 here
19:49danvet: not sure it still boots
19:49danvet: judging by all the dust it's under
19:49ajax: hell, we had an s3 virge driver at one point
19:50ajax: you definitely wanted to do your own triangle setup on the CPU side and feed all the span step parameters for every line of the tri to the GPU
19:50ajax: over pci33
19:50ajax: this was an _excellent_ idea and i have zero idea why the virge didn't do well in the market
19:51GNUtoo: I've been reporting various information about DRM to the drmdb database
19:51anholt__: that was early matrox, too, right?
19:51GNUtoo: And I'm not totally sure but I think this is my report: https://drmdb.emersion.fr/devices/072ee4df1896
19:52vsyrjala: danvet: i procured an i810-dc100 recently. already had the i740 :) should use those for i915 lmem upstreaming!
19:53GNUtoo: And I was told that about my report "<Putti> I hope [that the report was] not [reported] with the replicant kernel, since the replicant kernel adds ABGR888 even though it is not supported"
19:53danvet: I thought i740 didn't really have vram?
19:53danvet: all "agp is totally great&fast"
19:53vsyrjala: scanout is from local mem only i think. agp is for textures
19:53GNUtoo: emersion: what should I do? send a new report with a stock kernel?
19:53imirkin: lol, a discrete igp? :)
19:54ajax: anholt__: yeah, pre-g200 matrox, and whichever mach64s our driver didn't support, were all like that
19:54GNUtoo: and see if there is some differences?
19:54ajax: triangle setup engines were an actual innovation!
19:55ajax: "rage pro", i think, was where that came in. plain "3d rage" we never supported
19:57ajax: remember, "nostalgia" is derived from the words for "past" and "ache", it's not an intrinsically positive feeling.
19:57ajax: not that the past was better, that it hurt.
19:58imirkin: fwiw i have a random pci rage128
19:58imirkin: which came with the tnt2 (natural combination, right)
19:59karolherbst: I am sure I also have some r128 somewhere
20:02ajax: i've tried to stop caring about any gpu that isn't shaderful enough to manage gles2
20:11linkmauve: “20:06:48 imirkin> (the nintendo gamecube logo animation)”, it’s incorrect, I have the music playing in my head automatically and it is desynchronised!!! :D
20:11GNUtoo: emersion: sorry for the noise, the ARGB8888 also shows up with other non-patched kernels
20:19imirkin: linkmauve: moar fps
21:10emersion: GNUtoo: ok, cool!
22:14Putti: Hi, since android wants BGR formats instead of RGB I would like to make the Exynos FIMD display controller driver to support the BGR format too. The issue is that both BGR and RGB formats cannot be used at the same time, if I want to use BGR format I must disable all RGB formats (by setting VIDCON0 PNRMODE to BGR). This could be either a runtime option or module load time option. But for runtime option I couldn't a) find any current IOCTL for such
22:14Putti: operation b) I don't know if changing the pixel formats in runtime would break some applications in userspace. So I'm thinking module load time option. Sounds good?
22:16Putti: I could also probably just submit the patch and people will complain if it is wrong :)
22:18ajax: Putti: ... are you ever really needing to display both rgb and bgr _simultaneously_?
22:18ajax: or do i misunderstand what you mean by making the "display controller" support it? if it's separate from the rendering engine then...
22:19Putti: I don't know how people use computers :P
22:19Putti: ajax, I don't know what you mean with rendering engine, but it is separate from the mali gpu if that's what you mean
22:20Putti: it handles the HW planes and compositing those
22:20imirkin: you could reject modesets with weird format combinations
22:21anholt__: yeah, this sounds like the kind of weird constraint that atomic check is supposed to be able to handle.
22:21ajax: how many such planes do you have? can there be multiple rgb planes active at once? and yeah, what ^ imirkin said, if you allow multiple rgb planes at once then you can require them all be the same component order
22:22Putti: all the 4 HW planes must be at the same time either RGB or BGR
22:22imirkin: ajax: we live in the future - overlay planes do more than YUV now :)
22:23ajax: yeah, just require that then and userspace can be expected to cope
22:23ajax: a module load option would also work if you wanted to be super paranoid but if you can switch dynamically, no reason not to allow that
22:26Putti: hmm, I'm not quite sure where I could do this check at runtime, I will have to study the code a bit more to make sure this is possible. The plane initialization and video output / VIDCON is handled separately
22:39anholt__: arm64_test took too long to build on master since tomeu readded the kernel build, and so everyone's been rebuilding the container and it's timing out for them too. I've just triggered the pipeline in master again hoping that we hit the ccache and get a working container.
22:44anholt__: (https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/15 would help avoid this)
23:04GNUtoo: ajax: I'm unsure if I understood the problem correctly but as I understand changing some pixel formats in the encoder driver (VIDCON0) also affects the planes format (WINCON0)