00:26anholt: 8 second gles2 cts run on softpipe is just delightful.
00:27chrisf: anholt: how wide do you have to go to achieve that?
00:29bnieuwenhuizen: heh, no slow shader compile times causing stragglers?
00:30Kayden: now if only "draw black" wasn't a passing implementation of 80%+ of the GLES2 CTS :)
00:30anholt: gles31 is up at 1:11, but apparently draw_indirect.compute_interop.large.* is what's slow
00:31Kayden: that's crazy fast still
00:31Kayden: tons of parallel runners? or...?
00:31anholt: 72 threads, with deqp-runner
00:32Kayden: that's pretty amazing
00:48chrisf: now if only we made deqp not so hilariously cpu-bound internally? :)
00:49anholt: just need an optimized gl reference rasterizer of some sort?
00:49HdkR: Donate one of Microsoft's 16 socket Intel servers for ensuring it can saturate all cores? :P
00:50airlied: the horrors I usually see in deqp is pixel compares
00:50chrisf: the rast is kinda slow but also just strings junk everywhere, and interval stuff
00:50bnieuwenhuizen: chrisf: I have deqp-vk be GPU limited here :P
00:50bnieuwenhuizen: looks like tons of small cmdbuffers are hitting the command processor hard
00:53HdkR: https://www.edtittel.com/wp-content/uploads/2020/11/gigserv.jpg Such an intense server, 448 cores
00:53HdkR: 16 Xeon 8280L cpus in that
00:55bnieuwenhuizen: an actually shared memory server?
00:55bnieuwenhuizen: that is more than you can put on AMD ...
00:56HdkR: Sadly the talk didn't talk about the infrastructure of tying 16 sockets together https://www.youtube.com/watch?v=bV2Rb_LJRQ4
01:17agrisis: anyone know if a freenode channel exists that can help with configuring a mipi-dsi panel in the linux kernel?
01:18agrisis: I suspect a display timing issue due to the lcd only rendering part of my display
03:22dcbaker[m]: Anyone know Jonathan Marek's nick? I'm trying to apply one of their patches to 20.3 and the gitlab-ci pass/fail diff is annoying (d7ea266e6f)
03:23HdkR: flto: ^
03:28dcbaker[m]: also, can one of the ACO people confirm that ebfb9e181737e7ff7be638134410b919145a0f95 isn't relavent for 20.2. The modified code doesn't exist, but if someone can say for sure that it isn't needed I'd appreciate it
03:28dcbaker[m]: oh, wait, no, it is needed. never mind
03:30dcbaker[m]: gah, git is really bad at figuring out the diffs in the ci pass/fail lists
03:36dcbaker[m]: bnieuwenhuizen: aed8d30b507568b7fc0f32afca012f8def5aca16 doesn't apply to 20.2 (the function it changes doesn't seem to exist), what do you want to do with the patch?
03:37dcbaker[m]: I'm getting ahead of myself, it fixes another patch I haven't applied yet...
03:38flto: dcbaker[m]: just remove the two matching dEQP-VK.api.image_clearing.* lines in the 20.3 fails list
03:38dcbaker[m]: cool, I can do that
03:43dcbaker[m]: bnieuwenhuizen: Can you look at the second to last radv patch on the staging/20.2 branch? I had to do a little massaging and I'm not sure if I did it right. In particular I'm not sure if the `radv_describe_draw(cmd_buffer);` call in radv_cmd_buffer.c should stay or not
07:39airlied: tjaalton: do you package the device select layer from mesa? itshould be shipped anywhere lavapipe is installed, or really any mesa vk drivdrs
07:41tjaalton: airlied: libVkLayer_MESA_device_select.so? yes
07:49bbrezillon: kusma: I guess I need other reviews on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7922/diffs?commit_id=b6fa9d02d7e395d63d817896504d2fcdf87b8f55, do you know who I should ask?
08:32airlied: tjaalton: otherwise fs dir searxh order picks the default
08:32airlied: which can mean some people get lavapipe insted of hw driver
08:33kusma: bbrezillon: do you? I think the reasoning is solid, you've got a review, and there's been enough time for people to object... I would just merge.
08:36MrCooper: jenatali: glXSwapBuffers doesn't require a current context unfortunately
08:44pq: paulk-leonov, two encoders... I wonder if that works. I don't remember e.g. Weston doing *anything* with encoders except for checking which CRTC can drive which connector.
08:45paulk-leonov: pq: I think there would be two connectors as well :)
08:50bbrezillon: kusma: oh, ok, I thought I'd need more than one review on core changes
08:53pq: paulk-leonov, that's good then.
08:57kusma: bbrezillon: I would say it depends a bit on how long things have been out there, but perhaps I'm too eager? Dunno :P
09:06emersion: is libdrm still maintained? can't get any patch through…
09:08MrCooper: MR URLs?
09:10MrCooper: nvm, found them
09:11emersion: i have like 4 of them i think
09:11emersion: and there's also a uapi header update pending
09:14emersion: actually that one needs an update before merging, because we got AMD modifiers fixes in
09:14emersion: thanks MrCooper, wasn't sure who to ping
09:15MrCooper: there are no designated maintainers, mostly just people picking up stuff as they pass along
09:16MrCooper: two of the other MRs seem to have obvious candidates for prodding
09:17emersion: you mean eric?
09:17MrCooper: and danvet, yeah
09:20emersion: eric_engestrom, danvet: could you review https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/72 and https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/101 ?
09:23emersion: note, the rst one is already reviewed
09:23emersion: thanks danvet!
09:25danvet: emersion, feel like adding a gitlab target to build the docs and push them too?
09:25danvet: also pls apply for commit rights, imo more than justified
09:26emersion: sounds like a good idea
09:28danvet: emersion, I hit "merge when green" on the second one btw
09:35emersion: ah, eric no longer at intel, didn't know!
09:36emersion: eric_engestrom: are you still active on the gfx front, or is your new job completely unrelated? don't want to bother you with pings
09:39danvet: emersion, if you do the gitlab doc ci thing, pls add the magic link so it shows up in MR for easy review too
09:39danvet: iirc wayland has that, and I think MrCooper knows how
09:40emersion: yeah i've seen the merge request for this
09:40pq: weston has the preview
09:41MrCooper: Thunderbirded that for you ;)
09:41pq: having a diff of the generated docs would be cool too...
09:42emersion: that sounds… complicated
09:43emersion: GitHub/GitLab can do it on rendered markdown at least, but these are artifacts
09:44pq: sure, I'm just daydreaming :-)
09:44emersion: the plaintext diff should already help to hint where to look in the rendered docs
09:45pq: the job would probably pull from the latest master branch artifacts a tar-ball of generated docs, diff it, and render the diff into artifacts, maybe as HTML
09:45danvet: airlied, can you give me maintainer for mesa/drm? might be useful for approving people and stuff
09:46pq: sure, that works when doc changes are simple and not to e.g. Sphinx directives
09:47pq: a similar mechanism could be used for diffing test coverage reports
09:47pq: not with 'diff' of course, but something
09:48pq: hmm, actually no, it wouldn't work to pull old artifacts from master
09:48emersion: why? because they expire?
09:48pq: because the MR branch could be far behind master
09:50pq: you'd have to ensure it's rebased to master before the diff is useful
09:50emersion: so you need to compare with the base commit
09:50emersion: or yeah rebase, but that may fail
09:50pq: and a base commit may not have been run in CI at all, since CI does not run on every commit
09:51pq: oh well
09:51pq: last I looked, I didn't even find a good tool for comparing coverage reports to begin with
10:54kusma: ajax: checking "ctx->Extensions.*" is bad practice, and I've been working to rid us of this for a while. It's very easy to get things subtly incorrect when doing that. Your suggestion ends up enabling the enums on GLES 1.x. The right thing seems to be to actually check for the missing extension.
10:55kusma: ajax: in the longer run, I really want to rename this struct from "Extensions" to "Capabilities" or something. Because it's not at all about what extensions are enabled, it's about what the driver can and cannot do.
11:08airlied: danvet: think i did it right.
11:20danvet: airlied, thx
12:48Sumera: danvet: I tried applying the first patch https://patchwork.freedesktop.org/patch/315018/?series=63010&rev=1 here but there seem to be a few errors on compiling. Not sure if I did it right. git am and git apply both failed to apply patch so I did `git apply --reject old-patch.patch` instead. That created some .rej files and I added those manually
12:49Sumera: And I think i did it right because I compared the the diff to the original patch but I am getting some compilation errors so not very sure
12:51danvet: Sumera, could also be that other stuff in the kernel changed
12:51danvet: or vkms
12:51danvet: so yeah might need some fixing
12:51danvet: Sumera, can you pastebin the errors?
12:52Sumera: yep, seems like that. Also I think you mentioned something called git apply-mbox, um I couldn't find anything of the sort.. did you mean something else?
12:54Sumera: Daniel, here you go https://paste.ubuntu.com/p/5BJtHr49Qc/
13:00tzimmermann: airlied, danvet, still nothing in drm-misc-next-fixes for this week
13:04mripard: airlied: danvet: Nothing in drm-misc-fixes either
13:51ajax: kusma: i mean, yes, but there's nothing in the definition of OES_texture_float that says ES2 is _required_.
13:51ajax: written against the ES2 spec, admittedly, but
13:59ajax: that's a bit spec-weasel-y of me to say, and i agree it's not the ideal way to do it, but the question here is "can the driver actually store half-floats internally" and that's all _mesa_has_half_float_textures seems to be used for. that we're deriving the truth of that from whether some extensions would be supported is backwards, sure
14:32kusma: ajax: ES1 and ES2 are unrelated APIs
14:33kusma: ajax: we don't expose it in the extension-string either, so allowing the enums would just be silly.
14:33kusma: (for ES 1.x)
14:34mripard: tzimmermann: if you have some time, could you review https://email@example.com/ ?
14:36jenatali: MrCooper: Thanks for that... Looks like currently, wgl will crash and drisw will no-op if no context is bound during swap buffers
14:53danvet: Sumera, sorry missed your reply, you pinged the wrong dan
14:53danvet: I think that's just differences in baseline, some functions are named differently
14:53danvet: and some things changed
14:54ajax: kusma: that's a novel interpretation
14:54danvet: might be good to look at changes in that file and see why there's these functional conflictss
14:55danvet: Sumera, also perhaps push the tree you have somewhere to github or so
14:55danvet: or gitlab
14:56ajax: ... that they're unrelated, is novel.
15:02Sumera: danvet, oops another faux pas, sorry. Yep, doing the repo thing.
15:14Sumera: danvet: https://github.com/Sylfrena/linux/commit/b4638f89fa4e881c2ba716a26520bf4adde83eb0 does this work?
15:18danvet: Sumera, you accidentally added a .rej file
15:20danvet: Sumera, ok so for example the missing enable_writeback_connector
15:20danvet: it exists as vkms_enable_writeback_connector in upstream
15:21danvet: so need to adjust the code there
15:21danvet: or I'm massively confused
15:23danvet: similar for the other compilation failures we're seeing
15:24danvet: Sumera, e.g. when you look at the original patch, some code is moved from the old vkms_output_init function
15:24Sumera: I am quite baffled about the rej files but let me try to modify the rest
15:24danvet: to the new place
15:24danvet: but in the original one in upstream there's no if (enable_writeback)
15:24danvet: so we also need to remove it when applying the patch to upstream so it's the same logical change still
15:25danvet: yeah no worries, just confused for a bit until I look at the file ending :-)
15:25danvet: re-doing a change means you need to first understand what the original change did, which is sometimes a bit tricky
15:25danvet: so the 3rd compile issue you have is drm_connector_register
15:26danvet: that might just be a missing include or so
15:26danvet: #include <drm/drm_connector.h> should fix that one
15:27danvet: but I might be wrong here
15:28Sumera: Ah, okay. there is a drm_connector_unregister there as well so maybe not. I will look it up
15:40kusma: ajax: They are unrelated as in one isn't actually another version of the other. Yes, they confusingly share a name, but that's mostly a marketing decision. We threw OpenGL ES 1.0 out and started over when we did OpenGL ES 2.0. If that was a good choice or not I'm not sure sure of in retrospect, but it's what we ended up doing.
16:06zmike: mareko: ping re: your comment/patch in st_GetTexSubImage() about "the memcpy-based fast path" for matching format and type
16:07zmike: is this really faster than doing a blit for most scenarios? I just tested a case where I was hitting that fallback and it seems to be ~20% faster to go ahead with the blit
16:09FLHerne: Sumera: Look at `git help am` for the mailbox thing
16:09FLHerne: (git has notoriously obscure commands :-/)
16:09daniels: kusma: yeah, disjoint rather than unrelated I guess
16:13kusma: daniels: Yeah, fair.
16:25Sumera: FLHerne: Thanks! I did that, but had some issues with patch format so used apply -reject instead
16:45ajax: kusma: the code in st_extensions.c for this seems a little wonky. OES_texture_float doesn't require that it be renderable but we have the enable for it in rendertarget_mapping instead of texture_mapping for some reason
16:48ajax: looks like it's always been that way. am i wrong and it really does make it a render format?
16:54kusma: ajax: Hmmm, I don't think OES_texture_float makes it color-renderable, but I could be mistaken...
16:55kusma: But yeah, it seems like we require it to be renderable in st_extensions.c in order to enable it. I... think... that's... a... mistake?
16:55kusma: In GLES 2 "color renderable" is kinda the magic word we're looking for here.
16:56kusma: IIRC EXT_color_buffer_half_float and EXT_color_buffer_float is what does that part...
16:56ajax: yeah, the extn spec doesn't mention the word 'renderable' at all
16:56ajax: i haven't totally cross-referenced the tables it updates but i don't think they're the render format tables
17:02kusma: ajax: yeah, me neither, I guess I should check the tables.
17:02kusma: But I do seem to remember that some GPUs (like Tegra 2) supports using float-textues without float-rendertargets, and this being like that for this reason.
17:05kusma: Yeah, EXT_color_buffer_half_float for instance adds RGBA16F_EXT et al to table 4.5 as color-renderable, and OES_texture_half_float does not.
17:05kusma: I'm guessing we've just not supported hardware with these limitations yet?
17:05ajax: ... and we have EXT_color_buffer_float enabled unconditionally for es3? that seems sketchy
17:06kusma: ES 3 requires it, I believe
17:06ajax: extn spec says "Requires OpenGL ES 3.0" so that'd be a little curious
17:07kusma: Hmm, no.
17:07kusma: RGBA16F is only required for textures, not for render-targets
17:07kusma: (in es3)
17:07kusma: Yeah, that seems very questionable, indeed.
17:09kusma: I guess you could say that right now "ctx->Extensions.OES_texture_float" doesn't actually mean "do we support float-textures?", but actually "do we support texturing *and* rendering to float-textures?"
17:10ajax: that's certainly how it's being set in gallium anyway
17:10kusma: Yeah. It's not ideal, but I guess it's an interpretation that works. It just doesn't allow us to enable one without the other.
17:11kusma: For Lima, I have it on fairly good authority that the HW can actually do both.
17:16kusma: Even though it *might* not be exposed in the blob, not sure about that.
17:16kusma: Actually, probably even is, just maybe not in the most obvious code-paths.
17:18kusma: nevermind, seems like lima figured it out as a pixel-format also
17:36kusma: ajax: looks like 119002a648180ba1a20ed086adf2b1b306f81386 was, uh, just a bit careless when adding that extension. I'm guessing i965-tinted glasses or something?
17:44ajax: yeah. weird.
17:45ajax: been meaning to go through the format/extension stuff a bit more closely anyway so i'll add that to the list
17:46ajax: saw https://github.com/KhronosGroup/OpenGL-Registry/issues/450 and wondered why we don't have it at all yet
17:56zmike: mareko: cancel ping, trying to figure out how radeonsi is getting away with so much less cpu time in memcpy for pbo copying than zink does when it seems like they're doing the exact same thing...
18:12jenatali: Hm... probably instead of moving flush_frontbuffer I should just add a maybe-null context to it...
19:01airlied: zmike: likely zink ends up copying from vram?
19:04jenatali: airlied: Pretty sure the display target is allocated in system ram, since you'd need a context to do the copy
19:04jenatali: Oh nevermind, thought you were talking about my thing, didn't see his message :P
19:20tzimmermann: mripard, i'll take a look tomorrow
19:22airlied: tzimmermann, mripard thnaks for letting me know
19:22airlied: ill likely send fixes and next today
19:22airlied: as im out most of next week
20:43airlied: kusma: lavapipe CI landing, should make it easier to determine how bad the wips stuff is broken :-P
21:13Rush: hey there, is there an opensuse repo for Mesa 21.0-devel Git? I'd like to check out Cyberpunk 2077 but textures are broken on the latest stable Mesa :) On Mesa 20.2.4 the game starts but all textures are broken on my AMD card.
21:16HdkR: I'm only aware of the ubuntu ppa
21:24Rush: I remember somebody on this channel had an opensuse repo but it's been a while :)
21:32dontmindthings: So the danish hacker Agner Fog has for instance the performance numbers for his demo to all types of microarchitectures including intels Atom, for a skilled one that reveales basically clocking that the chips design has. Golden boy redesigned OS basing on this and on the new packed data paradigms. HdkR prefetching under any architecture is easy, all socs or other type of platforms also come with dma controller which can run this async. one
21:32dontmindthings: clocked burst with this along with one instruction in the program or shader accesses 1024 machine words from single cache entry. And all the masks are applied inside hw DMA circuitry, it does most the needed so to speak.
21:51dontmindthings: So i have all the code possible, those chips Atom and low grade entry level cause they are very cheap, are my favorites. All the drivers for the latest spec i also have, and new paradigm is so performant nd also low power and virtually with infinite instantaneous memory, for the dac we output unpacked data to be put onto the displays. This requires compiler bits for packing and new libc functions only.
21:52dontmindthings: all the hw ever manufactured in the world for calculating numbers or so to speak compute chips and any storage combination on them is supported, like HDD , SSD or some other.
21:58dontmindthings: human kind designed those chips, they have pretty much heavenly one :), and human kind can optimize them as well, i allready did :)
22:12Andrew_R: it seems mesa commits 72566fd92c27b39abe2057f6f23388ec40793dd9 + 80817b6e344258ac9b955f824ebf9019a0fc1610 broke clover compilation on i686/llvm-10 for me ... I reverted them locally and build works
22:12dontmindthings: cause my anchestors from the same specie i.e human kind designed those things, of course me as a sibling of the same kind, can understand every last bit they designed also, common sense.
22:14dontmindthings: the way they did it, and they i modified the paradigm, should get you real clues about how rich planet earth actually is in resources.
22:14kisak: Andrew_R: please make an issue report on gitlab so it it doesn't get buried in chat log
22:21dontmindthings: So such concepts as google, facebook, netflix and many other sw companies almost do not exist even today at least as of yet, and even there are rumours that it never even existed at least facebook, what existed was persian located jews one of the tribes of the five of them, who rebuilt the financial system, and took over the resources, according to some info one of such was marks granny. i.e Rockchild.
22:32dontmindthings: You know the way Magnus Carssen beats grand champions should hint that scandinavian brainpower is not really weaker even though jews rebuilds were influencial enough, so that scandinavians should be in posession of fewer resources or control less of what the mentioned do.
22:33Andrew_R: kisak, https://gitlab.freedesktop.org/mesa/mesa/-/issues/3962
22:51dontmindthings: I am totally not against those jews to have such resources when they have internal content and smartness, would be a lot discriminative to ban other races for them to make impossible to own some as well, like they tried to do with me, and they did allready. I also diserve healthcare and diserve the salary what i earn, as simple as that.
23:04byte4byte: lol i see ya HdkR
23:04byte4byte: what is this channel driver development?
23:07HdkR: It's the mesa driver stack development channel.
23:15airlied: jenatali: what's the use case for spirv->dxil over going via nir, just reduced overhead?
23:16jenatali: airlied: It goes via nir
23:16jenatali: It's just a dedicated target which only does that
23:16airlied: ah I just assumed it was something new, should have looked a bit closer!
23:16jenatali: Existing targets would be the full d3d12 driver, or the CL frontend which only works for kernel spirv
23:17jenatali: airlied: No worries :)
23:38bnieuwenhuizen: dcbaker[m]: the backport seems correct wrt radv_describe_draw, thanks!