01:28 zzoon: Hi, I've just sent an email to mesa-dev for request for granting access.
01:29 zzoon: That's the way to request permission as far as I heard..
01:29 zzoon: Hopefully the request would get approved..;-)
01:44 zf: okay, now I'm *sure* fd.o went down
03:18 bl4ckb0ne: is it possible to run a specific test with a specific gl version on piglit?
03:57 bl4ckb0ne: also I notice waffle use wl_shell, is there a reason for not using xdg_shell?
04:01 Kayden: https://gitlab.freedesktop.org/mesa/waffle/merge_requests/60
04:01 gitbot: Mesa issue (Merge request) 60 in waffle "wayland: Port to xdg-shell stable" [Opened]
04:10 bl4ckb0ne: oh, good to know its being taken care of
04:10 bl4ckb0ne: didnt thought about searching inthere
06:31 airlied: MrCooper: I tried to do what you asked in that MR but I think I got it wrong
06:32 airlied: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3805 the pipeline said no
06:32 gitbot: Mesa issue (Merge request) 3805 in mesa "gallivm/s390: fix pass init order on s390 with llvm 8" [Gallium, Llvmpipe, Opened]
06:52 Manoa: guys I have a tiny question about libraries, if I have say a so and say a program loads the so, does the entire so from start to end becomes part of the program's address space or does only the used code of the so loads into the program address space ?
06:59 airlied: Manoa: it doesn't work like that
07:00 airlied: the so gets mapped (not loaded) into the process address space
07:00 airlied: it only gets loaded when something faults in the pages, i.e. executing code in the shared library
07:04 mattst88: Manoa: take a look at https://en.wikipedia.org/wiki/Demand_paging and some of the See also links at the bottom
08:03 Manoa: thank :)
08:04 MrCooper: airlied: ah, I forgot a step, see my last comment
08:05 MrCooper: ajax: I could only see that at all working automatically if the piglit results don't change, in which case is there a point?
08:05 mlankhorst: Lyude: will pass both to drm-fixes, sec
08:06 MrCooper: ajax: a daily pipeline which pulls in current piglit might make sense though, so we get a heads up when something changes
08:06 Manoa: airlied, that's what I was affraid of :x VIRT usage is proportional to the whole size of the library not just the sections that are "active" :x
08:06 Manoa: I wish that wasn't like that xD
08:08 Manoa: I wanne try to use huge pages but if im understanding this correctly, in terms of address space it's not going to make any diffrence :x
08:08 MrCooper: if you have to worry about virtual address space, upgrade to 64 bit ;)
08:09 Manoa: the system is :) it the games that the problem xD
08:09 Manoa: my mods they load all the way to 4 giga :x
08:10 HdkR: rm -Rf mods/
08:10 Manoa: lel
08:10 Manoa: realy ? do you know what a graphics it's ?!
08:14 HdkR: But yes, huge pages don't reduce address space usage. You'd get more gains by just having objects getting unmapped from process space once virtual memory runs out
08:15 HdkR: Textures are a big one
08:15 Manoa: yhe that the problem :x
08:15 HdkR: I presume the Nvidia blob doesn't hit this since I think that driver stack handles that problem
08:16 HdkR: Which is probably why the problem wasn't noticed before?
08:17 Manoa: last time I tested this was 2.5 years ago and today WINE is grate, I compiled 5.1 and could load same number of mods as on windows 7
08:17 HdkR: Well, memory usage would change significantly from everything involved in 2.5 years :)
08:18 Manoa: so far only tested in one game, but the limit is still... limiting lel so I am starting to think how to increase the VIRT as mutch as I can (thare is still crashing and texture bugs from VIRT use)
08:19 Manoa: what I thinking about is manually delete some code from mesa and LLVM and compile them with -Os
08:19 Manoa: and -g0 etc...
08:20 Manoa: one of the tricks that helped in this specific game is unpacking the archives and leaving them in unpacked state from mod dir, this saved alote of VIRT
08:28 Manoa: in the way that it's going, linux mybe will overtake windows in his own game (lel)
08:29 mripard: Lyude: I'm not sure :)
08:29 mripard: danvet: is that alright to merge drm-fixes into drm-misc-next ?
08:30 danvet: mripard, yeah
08:30 danvet: if you have an excuse
08:30 danvet: but generally backmerging -rc1 is the worst
08:30 danvet: so maybe backmerge -rc2 on Monday
08:31 danvet: mripard, other option is to backmerge drm-next
08:31 danvet: I think that hasn't moved forward yet
08:31 mripard: danvet: yeah, that's what I was looking at
08:32 danvet: just good practice to kinda avoid a backmerge of the unfixed merge window :-)
08:32 mripard: but the last drm-misc-next-fixes seems to be set indeed for -rc2
08:32 mripard: Lyude: which patch did you need?
08:32 danvet: mripard, drm-next, not something else
08:32 danvet: before it rolled forward
08:33 danvet: hm rolled forward already
08:33 danvet: mripard, c0f00d270eba3cba688dd62a7b1a742ad289b879 from drm-intel is what I generally recommend
08:33 danvet: i.e. pull in drm-next of the final merge window pull
08:34 danvet: you could just pull in that pull request from airlied
08:34 danvet: drm-next-2020-02-07
08:36 mripard: yeah, but drm-misc-next-fixes was merged by 7ebdc26a315a, which is after -rc1
08:36 mripard: so that tag doesn't have drm-misc-next-fixes-2020-02-07
08:37 mripard: which was what Lyude seems to want
08:37 danvet: ah ok if that's what you need then I guess wait until -rc2 on Mon
08:37 danvet: I can roll drm-fixes forward if airlied doesn't
08:37 mripard: ok, I'll wait for monday then :)
08:37 mripard: thankS!
08:38 Manoa: guys just to mention, I tested rc2 for some time now and I diden't have any problems :)
08:46 MrCooper: Manoa: seems unlikely that shared libraries take up significant virtual address space compared to things like textures
08:49 HdkR: pmap on the pid would allow them to confirm if saving a potential couple megs of memory would help
08:51 MrCooper: unless there's an LLVM build with debugging symbols in the mix maybe
08:51 MrCooper: that's ~360 MB here
08:52 HdkR: and a non-debug build here is ~66MB
08:53 Manoa: yhe LLVM did looked a littel big
08:53 Manoa: but without options mesa also take a cuple 100
08:53 Manoa: mesa not realy the big problem, I can reduce him to like 5 mb
08:55 Manoa: yhe so's take some space eh ? thare is realy no other way to reduce VIRT, textures are big objective to give the best graphics
08:58 Manoa: I will test pmap, thank :)
09:46 medfly_: hi. wheres the separate tree used for drm development for things that end up in linux later?
10:16 medfly_: Got it (git://anongit.freedesktop.org/drm/drm).
13:50 imirkin_: is there a "glxinfo" for vulkan?
13:51 imirkin_: (i.e. something that shows that things are "good", or, conversely, "bad")
13:51 pendingchaos: "vulkaninfo"
13:52 imirkin_: ok, good to know that exists. will track down why i don't have it...
13:52 imirkin_: aha, part of vulkan-tools
14:58 bl4ckb0ne: can I run a single test with piglit or do I have to run the whole opengl suite each time ?
15:02 imirkin_: bl4ckb0ne: sure
15:03 imirkin_: just run the binary
15:03 imirkin_: piglit is a bunch of small GL programs which happen to print things to stdout in a fairly consistent manner + tools to run them all
15:04 imirkin_: (some tests do end up doing a bunch of different things, and in that case it can be harder to break up)
15:06 bl4ckb0ne: so i can run the binary itself to be sure that everything runs, then run the opengl suite to have the nice report?
15:07 imirkin_: sure
15:07 imirkin_: you probably want to run the test with -fbo -auto
15:07 imirkin_: unless it's a "special" one
15:08 imirkin_: (e.g. wants front-buffer rendering, etc)
15:12 bl4ckb0ne: thanks!
15:32 bl4ckb0ne: heh, without any surprises, nothing works!
15:32 bl4ckb0ne: ill take care of that after $dayjob
15:33 imirkin_: yeah, i'm suspicious when things work on the first try
15:33 imirkin_: that's usually a sign that things are _so_ broken that the tests aren't even running
15:34 bl4ckb0ne: fragment shader seems ok, it's the vertex who's missing my extension
15:35 bl4ckb0ne: also is there a way to run piglit on a local mesa build or do I have to install everything on the system?
15:35 imirkin_: sure ... same way you run any application against a local build
15:35 imirkin_: it's just a regular GL application that does some GL stuff and then prints stuff out to stdout/stderr.
15:35 bl4ckb0ne: messing with LD_LIBRARY_PATH?
15:35 imirkin_: that's what i do.
15:36 imirkin_: if you don't "install", you probably also have to mess with LIBGL_SOMETHING_PATH
15:36 imirkin_: but usually i install into ~/install or something
15:36 imirkin_: so i don't have to screw around with that weirdness
15:37 bl4ckb0ne: LIBGL_DRIVERS_PATH?
15:37 imirkin_: sure, why not
15:37 imirkin_: which has to point to bla/dri which has the foo_dri.so file
15:37 bl4ckb0ne: huh nice
15:37 bl4ckb0ne: there's a couple of other LIBGL env var
15:40 MrCooper: kazlaus: is there a bug report about the issue we discussed yesterday?
15:40 bl4ckb0ne: thanks for the pointers imirkin_
15:40 kazlaus: there might be one for the hmd thing
15:40 kazlaus: it was probably from october or november last year I think
15:40 kazlaus: actually there was an xserver bug associated with this I think
15:51 ajax: MrCooper: debugging symbols in a dso don't contribute to its virtual address space when loaded
15:51 MrCooper: nice
15:52 ajax: the sections containing them don't have an associated LOAD header so they never get mmap'd
15:54 ajax: was there some discussion recently about flaky a630? just looking at the pipeline log.
15:56 MrCooper: there was, and some more tests were added to the skip list recently, but clearly not enough yet
16:22 danvet: bbrezillon, narmstrong [PATCH] drm/atomic-helper: fix kerneldoc <- pls ack
17:35 pcercuei: A question about DRM panels...
17:35 pcercuei: There is no "set mode" callback?
17:36 pcercuei: I have a panel that supports multiple pixel formats with a magic register
17:53 lynxeye: pcercuei: is there a point in changing it at runtime? Would it be enough to have a DT property to specify the format for the system and then just init the magic register with the correct value and expose the corresponding format as the panel bus_format?
17:54 pcercuei: Of course there is a point in changing it at runtime
17:55 pcercuei: some apps want RGB565, some apps want RGB888
17:55 pcercuei: Some even want XBGR1555
17:55 lynxeye: pcercuei: but doesn't your scanout engine convert between in-memory format (what the app sees) and the panel bus format?
17:56 pcercuei: No, it has to be converted in software
17:57 lynxeye: pcercuei: uh, my condolences.
17:59 pcercuei: heh
18:54 jvesely: dcbaker: is there a simple way to cleanup mako cache? the summary script complains about 'six' after the recent changes
18:56 jvesely: i'd also expect it to figure it out since the templates were changed, any reason why mako wouldn't do that?
18:59 jvesely: ok, turns out the removal is broken and left references to six in testrun_info.mako
19:09 sravn: pcercuei: IS what you are asking for some way the connector can pass back the selected mode to the panel, so the panel can adjust to the selected mode
19:10 sravn: pcercuei: Almost all panels today announce a single mode only, and the current design reflects this
19:13 dcbaker: jvesely: https://gitlab.freedesktop.org/mesa/piglit/merge_requests/227
19:13 gitbot: Mesa issue (Merge request) 227 in piglit "templates: Remove last remaains of the six module" [Infrastructure, Opened]
19:14 sravn: pcercuei: And what you refer to is that something like ilitek 9331 where one can select between a 9-bit and a 18-bit itnerface?
19:15 sravn: pcercuei: Or 8-bit or 16-bit that is.
19:16 pcercuei: sravn: actually, the interface is fixed to 24-bit, but the panel supports various sub-pixel orderings
19:17 pcercuei: RGB, BGR, etc
19:18 imirkin_: sounds like what you want isn't the mode, it's the fb pixel format
19:18 airlied: MrCooper: closer https://gitlab.freedesktop.org/airlied/mesa/-/jobs/1636144 bit armhf is choking somewhere
19:18 imirkin_: mode doesn't have anything about fb formats afaik
19:23 sravn: pcercuei: No matter if this is fb or mode then you are right, there is no such callback today. And we should add it so the display driver have the possibility to request the panel to adjust to the selected fb pixel format, bus format and mode
19:23 pcercuei: imirkin_: correct
19:24 imirkin_: where is the code that transforms the fb to the "right" format?
19:24 imirkin_: or do you just expose the one format that happens to work out?
19:25 pcercuei: I only expose one format right now
19:25 imirkin_: and where do you read the fb contents out?
19:26 imirkin_: or is it all dma?
19:26 pcercuei: DMA
19:26 imirkin_: where do you set up the dma address for the fb then?
19:27 pcercuei: in the plane's atomic_update function
19:27 pcercuei: Why does it matter?
19:27 imirkin_: can't you update the format then too?
19:27 pcercuei: Not without converting the whole framebuffer in software
19:28 imirkin_:is unclear of the goal
19:28 imirkin_: if the DMA can only consume one fb format, and you don't want to convert in software ... what's the discussion?
19:33 Lyude: mripard: basically I was trying to commit a pretty simple patch but it semeed like some of the commits I had in drm-misc-fixes-next aren't in drm-misc-next: https://patchwork.freedesktop.org/patch/msgid/20200122194846.16025-1-lyude@redhat.com
19:36 pcercuei: imirkin_: I don't see what you don't understand. My panel only does RGB888, which means my framebuffers only support RGB888
19:36 pcercuei: The idea is to add support for BGR
19:36 imirkin_: ok
19:36 imirkin_: so why don't you just do that?
19:36 jvesely: dcbaker: thanks
19:36 pcercuei: imirkin_: because I can't?
19:37 imirkin_: expose both RGB888 and BGR888 and in your atomic_update set the hw flip bit?
19:37 pcercuei: I would do that, if there was a "atomic update set" for the DRM panel
19:37 imirkin_: the format is a property of the fb
19:38 imirkin_: so should be able to do it whereever you configure the hw to read the fb
19:38 pcercuei: No, because it's not something that the LCDC can do
19:38 pcercuei: it's something that the LCD panel does
19:38 imirkin_: oh, i see.
19:39 pcercuei: So it needs to go down the stack
19:39 imirkin_: so the panel never sees the fb at all?
19:39 imirkin_: (i.e. the drm panel object is never informed of the fb)
19:39 pcercuei: correct
19:39 imirkin_: sadness.
21:21 MrCooper: airlied: the meson-armhf job still needs LLVM_VERSION: 7, otherwise more extensive changes would be needed for the arm_build image
21:31 airlied: MrCooper: ah
21:31 MrCooper: fine to put that off for later I think
23:07 Kayden: mareko: have an annoying question for you... shouldn't si_fence_server_sync be doing si_flush_from_st() using sfence->gfx_unflushed.ctx rather than sctx?
23:08 Kayden: if the fence you're trying to wait for is deferred, don't you need to actually flush that before adding a dependency on it?
23:08 Kayden: as it, it looks like you're flushing the current context's work, not the deferred work
23:32 Kayden: I suppose you can defer the submission of that work further.... but when submitting the thing containing the dependency, you'd have to also submit the thing it waits for
23:32 Kayden: which seems...complex
23:50 mareko: Kayden: my understanding is that the context should wait on the fence before continuing execution; the fence can be from a different context; first it flushes the context, because previous work doesn't need to wait for anything, and the dependencies are added, so that any future comman buffer won't start execution before the fence is signaled
23:51 mareko: not an annoying question at all, very good question actually
23:52 Kayden: right...the flush is to make any queued work for the current context not wait because it doesn't need to
23:53 Kayden: ickle: I think iris_fence_await might be OK. The syncobjs it adds a dependency on do exist - we create them when creating a batch. That batch just hasn't been submitted yet.
23:53 ickle: they aren't know to be fences until the submission
23:54 Kayden: In theory, we could submit the batches in the wrong order...but wouldn't it just sit in the kernel's queue until those syncobjs are signalled by something?
23:54 ickle: you need dj-death's WAIT_FOR_SUBMIT
23:55 Kayden: mareko: How do you guarantee that the dependencies are actually submitted beforehand? Or do you not - and just submit both - and let the kernel sort out the ordering?
23:56 mareko: Kayden: I guess an app flushes the context
23:56 Kayden: like, what guarantees the fence from the other context actually is submitted before the context that server_sync'd against it
23:57 mareko: kernel submissions are atomic from the userspace point of view
23:57 Kayden: I guess if they don't flush then they can deadlock or something
23:57 mareko: yes, they have to flush
23:57 Kayden: but that's considered their fault then
23:57 mareko: I don't think you can get a future fence, can you?
23:58 Kayden: Well... I think I am, with deferred flushes.
23:59 Kayden: Context A does a deferred flush. It has a fence in that batch, but it's not been submitted. Context B does a server_wait_sync on that fence, marking a dependency on it. But...it still hasn't been flushed. So it's...future
23:59 Kayden: if we didn't defer then it'd be fine