<Lynne>
about 2.5x slower than what I should be getting, but at least I can test stuff
crabbedhaloablut has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
<mareko>
I have a working prototype of passing glXSwapBuffers into glthread and doing it asynchronously, so that we never have to synchronize glthread at the end of every frame, hopefully it's legal
kzd has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
sgruszka has joined #dri-devel
DodoGTA has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
The_Company has quit [Remote host closed the connection]
godvino has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
lemonzest has joined #dri-devel
<mupuf>
DavidHeidelberg[m]: not the same one, more of a how-to on how to setup a CI system at home
<mupuf>
If you want to discuss about Mesa CI, I suggest you propose another workshop
<mupuf>
I don't see much use for it honestly, as we are yet to finish implementing everything we talked about
Duke`` has joined #dri-devel
itoral has joined #dri-devel
<mupuf>
DavidHeidelberg[m]: the point of the workshop I want to organise is to show interested devs how plug-and-play vland easy maintenance valve infra is
<mupuf>
Hopefully, we'll have changed the name by then
<mupuf>
And implemented our own gitlab runner so that execution in the farm would be transparent to gitlab projects
mvchtz has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
fab has joined #dri-devel
fab has quit []
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
vsyrjala has quit [Remote host closed the connection]
glennk has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
jkrzyszt has joined #dri-devel
glennk has joined #dri-devel
frieder has joined #dri-devel
fab has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
vsyrjala has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
godvino has quit [Quit: WeeChat 3.6]
tursulin has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
crabbedhaloablut has joined #dri-devel
DodoGTA has joined #dri-devel
DodoGTA has quit [Remote host closed the connection]
<mupuf>
Why go with labgrid though? It's pretty much the same design as lava... which means yet another indirect job submission system
<zmike>
mareko: madmlan
<zmike>
the ghost of ajax will surely haunt you for this
sumits_ has joined #dri-devel
sumits_ has quit []
sumits_ has joined #dri-devel
sumits has quit [Ping timeout: 480 seconds]
andrey-konovalov has quit [Ping timeout: 480 seconds]
andrey-konovalov has joined #dri-devel
sumits has joined #dri-devel
danylo has joined #dri-devel
<shoragan>
mupuf, labgrid intentionally has a very different design compared to LAVA. no dispatcher on the system connected to the DUT, only a relatively simple 'exporter'. most of the logic runs on the client. full support for interactive use via a CLI from a remote client.
* shoragan
one of the initial labgrid authors
<shoragan>
DavidHeidelberg[m], do you have a link for the labgrid integration?
<DavidHeidelberg[m]>
shoragan: not yet, for now I just tested it talks to each other (switch sockets & stuff)
<DavidHeidelberg[m]>
I wired only the gitlab to labgrid not the sending job itself yet
smiles_1111 has joined #dri-devel
<mriesch>
sravn: time for yet another st7789v series :-) should i base on -rc1 or on the v3 of sre 's series?
sumits_ has quit []
<shoragan>
DavidHeidelberg[m], ah, if you have any questions, we're happy to help in #labgrid
aravind has quit [Remote host closed the connection]
heat has joined #dri-devel
Company has joined #dri-devel
ngcortes has joined #dri-devel
yuq825 has quit []
<tyalie>
hi. I'm rather new here and I might need some help ^^ I asked yesterday already, but I think that got overlooked as it was in the midst of a conversation. I would like to introduce a new video format to the linux kernel / 4CCs, but I'm not fully sure how the governing rules are around it, who to CC and how likely my endeavors would be if I might do
<tyalie>
a post to the ml?
<zamundaaa[m]>
zmike: just run the compositor with llvmpipe, it should be immediately visible
kzd has joined #dri-devel
kzd has quit []
<pq>
tyalie, I think it should be fine, the requirement for adding DRM pixel formats are much more lax than adding anything else that touches UAPI. Maybe look at the history of include/uapi/drm/drm_fourcc.h?
<pq>
tyalie, definitely cc dri-devel@ mailing list, otherwise I don't know. I guess the usual check_maintainers.pl applies, or what was that script that tells you who to cc?
<emersion>
tyalie: git-send-email to the ML yeah, CC maintainers and people who touched the file recently
<javierm>
arnd: if you can review my v5 of the FB_CORE split when you have some time, that would be awesome too
<zmike>
zamundaaa: is there an easy way to get it to run with llvmpipe? LIBGL_ALWAYS_SOFTWARE doesn't work in this case
<zamundaaa[m]>
Yeah, run the whole system with simpledrm
<zmike>
ah
<zmike>
hm
kzd has joined #dri-devel
<zmike>
not entirely sure that's feasible for me atm
<tyalie>
emersion What pq says. I'm currently working on introducing thermal cameras to libcamera and would need a frame format that can represent temperatures. float 32 would be good enough for most cameras out there
<zamundaaa[m]>
zmike: a VM would work too
<tyalie>
my hope is, that in the future everyone can just attach one of the supported thermal cameras and do the processing / colorization / ... with e.g. OpenCV or the like
<zmike>
maybe something I can aspire to between other things
<gfxstrand>
dj-death: How did registers shake out this morning?
<zmike>
not sure what to do about this
<mareko>
I find RADV harder to read after clang-format reformatting, it uses a code style that looks like a machine wrote it, not a human
<dj-death>
gfxstrand: I started it just before the meeting :)
<pq>
tyalie, makes perfect sense to me, FWIW.
<dj-death>
gfxstrand: ongoing :)
<gfxstrand>
dj-death: Cool
<mareko>
Venemo: ^^
<zmike>
zamundaaa: hm isn't simpledrm used by default in newer fedora releases?
<emersion>
zmike, zamundaaa[m]: wlroots doesn't support llvmpipe, because it requires EGLImage
<emersion>
need a new GL ext to make it work
<emersion>
(llvmpipe requires EGLSurface')
<zamundaaa[m]>
emersion: kwin also requires eglimage
<mareko>
Venemo: I would revert the reformatting just to get back to the original Mesa style
<emersion>
hm, maybe it works with DMA-BUF + a display-only device
<zamundaaa[m]>
zmike: yes it is. It's used if you use the nomodeset kernel boot argment
<emersion>
maybe try vkms?
<zmike>
I suppose it's too much to ask that this codepath be hit in nested compositors for testing :/
benjaminl has quit [Ping timeout: 480 seconds]
<eric_engestrom>
zmike: yeah sorry, I meant to post a comment about cancelling this job but I got distracted
fxkamd has joined #dri-devel
<eric_engestrom>
you ran all the jobs in the pipeline for a vulkan-only change, which I assumed was a mistake so I cancelled the test-gl job
<daniels>
zmike: did you cancel the job?
<eric_engestrom>
sorry about not posting a comment about that
<daniels>
ah
<daniels>
mid-air collision
<eric_engestrom>
:)
<eric_engestrom>
zmike: feel free to re-start the job if you really do want these to run
<zmike>
it's a zink-only change
<zmike>
you canceled literally the only job that was important lmao
<eric_engestrom>
haha sorry
<eric_engestrom>
but perhaps ci_run_n_monitor could be good to run the jobs that are useful and not the rest :]
<zmike>
yeah maybe
<zmike>
I'm trying to multitask
<zmike>
unsuccessfully
<zmike>
in the future though please don't randomly cancel other peoples jobs
<mupuf>
shoragan: Thanks for sharing :) I may have misunderstood, but since you need console drivers, doesn't it mean you still send commands and parse the output, like lava does?
<mupuf>
And you still rely on rootfs too... Which makes integrating with CI pipelines annoying at best :s
<eric_engestrom>
zmike: yeah sorry, I shouldn't have done that indeed
<Venemo>
mareko: I'm sorry about your frustrations with the style
<Venemo>
is there anything specific we can improve in it?
<arnd>
javierm: I've rebased my randconfig tree on top of linux-next now and applied your patches on top to give them some more testing. It all looks good to me already, will reply once the build system confirms that, or it finds a bug
<mupuf>
It's a neat project, and it seems perfect for development purposes. Just not sure about using it in a CI environment since there doesn't seem to be much in the way of verification that the DUT is the one you wanted to run on, same for the serial console
<javierm>
arnd: perfect, thanks a lot!
<emersion>
hm, so i'm running wlroots with vkms and llvmpipe but it required a fair amount of env vars
<emersion>
let's try to see if i can simplify the process
<mareko>
Venemo: there 2 issues: 1) the placement of line breaks, which can be disabled by setting the column limit to 0, which doesn't touch line breaks determined by the user, but the current line break changes made by clang-format would have to reverted, 2) every line of multi-line expressions is not indented equally, which doesn't have a known solution AFAIK
sgruszka has quit [Remote host closed the connection]
<mareko>
we reformatted radeonsi by clang-format long before this was a thing to get rid of tabs, and we have been manually reverting some of the changes clang-format made
<shoragan>
mupuf, yes, we use the console for remote control, but the code to do that runs on the "client", the CI runner in your case, so is easy to update. alternatively, you can use SSH to the DUT.
<mupuf>
shoragan: wait, where is lava's code running then, if not "the client"?
<shoragan>
in contrast to lava, we usually provision the full software to the DUT (including the bootloader) via USB or network, so we are always sure we know exactly which SW we're testing.
<mupuf>
That is indeed the way to go!
<cambrian_invader>
anarsoul|2: from what I can tell the BO is allocated as a dumb buffer, which means the kernel is aware of the width/height/bpp
<shoragan>
mupuf, LAVA has the concept of a dispatcher. the scheduler assigns a job definition (basically a custom yaml-based DSL) to the dispatcher. the dispatcher the runs local python code to process the steps in the job definition one by one. when it's done, it pushes the results back to the scheduler
<cambrian_invader>
is xf86-video-armsoc supposed to do the alignment?
<mupuf>
shoragan: in the infra I develop, the code runs on the DUT itself. The console is for feedback only (or interactive sessions)
<shoragan>
so there is no direct communication beween the client (i.e. CI runner) and the dispatcher during the job execution
<cambrian_invader>
I don't see other utgard drivers in that repo doing any alignment
<mupuf>
shoragan: great, same in the infra I work on :)
<mupuf>
You can restart the service, and the jobs keep running
<mupuf>
Practical for live-updates
<cambrian_invader>
that said, I also tried with a different window size (naturally 16x16 aligned) and I saw some errors
<cambrian_invader>
so there is more to debug besides this...
<shoragan>
mupuf, LAVA's architecture precludes interactive use, though, as everything has to go through job definitions
<shoragan>
even with lava you often have a process on the CI runner waiting for the results though, so runner updates aren't much easier in practice
<shoragan>
but I don't have a public test suite for that, sorry
<shoragan>
mupuf, ah. as we're more product-focused, we try keep the SW as close to the release version as possible, so avoid test instrumentation on the DUT
<dj-death>
gfxstrand: fossils look good on 5 platforms (skl, icl, tgl, dg2, mtl)
<dj-death>
gfxstrand: it's either a draw or a slightly spill/fill improvement on a couple of apps
<emersion>
hrm, MESA_LOADER_DRIVER_OVERRIDE=swrast dies with "libEGL fatal: did not find extension DRI_IMAGE_DRIVER version 1"
<emersion>
LIBGL_ALWAYS_SOFTWARE=1 doesn't work with EGLDevice
<zmike>
🤔
<emersion>
libEGL warning: Not allowed to force software rendering when API explicitly selects a hardware device.
<emersion>
i should probably add a way for wlroots to select the software rendering device
<emersion>
but then… not sure how DMA-BUF stuff would work…
<emersion>
it doesn't seem like mesa uses llvmpipe with vgem :/
<zmike>
llvmpipe doesn't support dmabuf
<emersion>
well, it does
<emersion>
llvmpipe + vkms gives me DMA-BUF support
<emersion>
llvmpipe + vgem doesn't
<mupuf>
shoragan: right, there can be some cases where you indeed want to test from the outside
<mupuf>
I'll keep that in mind when I'll be ready to remove this possibility in the infra I work on. Can be useful as an opt-in
<mupuf>
Thanks for spending the time to answer my questions! Much appreciated
<shoragan>
mupuf, we also use these options often for interactive development, as we use the same boards in the farm for development and CI (over night)
<shoragan>
(which was the main reason for starting labgrid instead of using lava)
<gfxstrand>
dj-death: \o/
<mupuf>
shoragan: yeah, easy interactive access to boards is a MUST HAVE!
<shoragan>
:)
<dj-death>
gfxstrand: let me just look at the write_mask thing
<gfxstrand>
There was a write_mask thing?
benjaminl has joined #dri-devel
<sravn>
mriesch: I saw you posted the patches - good. Will try to take a look at them
<austriancoder>
zmike: does your MR affect # of draw_vbo() calls?
<zmike>
no
<austriancoder>
zmike: without our MR I get 6 calls to draw_vbo() with our MR I only see 1 - the state emitting per se looks fine
<zmike>
🤔
<austriancoder>
lets see what happens
<mriesch>
sravn: yeah i figured that one part of the patches applies on both sre 's series as well as on rc1, so i split that off. sorry for the noise here
<mriesch>
and thanks, feedback will be appreciated
<MrCooper>
emersion: how about MESA_LOADER_DRIVER_OVERRIDE=kms_swrast ?
<emersion>
MrCooper: it tries to allocate dumb buffers
<emersion>
this fails on vgem
<emersion>
... maybe that's what's used on vkms
<emersion>
hm, I don't even know, is vgem able to allocate memory?
cmichael has quit [Quit: Leaving]
ced117 has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<gfxstrand>
[wu
Company has quit [Read error: Connection reset by peer]
lynxeye has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
Company has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
djbw has joined #dri-devel
lstrano has joined #dri-devel
junaid has joined #dri-devel
mvchtz has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<karolherbst>
how can I get `MESA_LOADER_DRIVER_OVERRIDE=nouveau` to work in a meson devenv?
<karolherbst>
ehh wait.. seems to be my mistake, but uhhh.. the runtime behaves weirdly
rasterman has quit [Quit: Gettin' stinky!]
guru_ has quit []
oneforall2 has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
camus has quit [Remote host closed the connection]
<gfxstrand>
dj-death: Does your "looks good" count as an RB?
digetx has joined #dri-devel
digetx has quit []
<dj-death>
gfxstrand: still reading a bit through the vec4 changes which I'm not super familiar with
mvchtz has quit [Ping timeout: 480 seconds]
digetx has joined #dri-devel
mvchtz has joined #dri-devel
<arnd>
javierm: I get a merge conflict against d2aff54834766 ("fbdev/hecubafb: Select FB_SYS_HELPERS_DEFERRED"), if you rebase it's probably easier to leave CONFIG_FB_HECUBA in drivers/video/fbdev/Kconfig
<dj-death>
gfxstrand: rb
<arnd>
javierm: it's actually a driver symbol, not a core one
<arnd>
FB_MACMODES should also remain there I guess
<javierm>
arnd: you got a merge conflict with v4 or v5? I thought that rebased on top of Thomas' series
<javierm>
arnd: I see. Since wasn't inside the "Frame buffer hardware drivers" sub-menu, I assumed that was a core symbol
<javierm>
arnd: probably need in v6 a preparatory patch to move those inside that menu ?
sravn has quit []
<lumag>
alyssa, in ~7hrs the test will finish. Looks good up to now.
Haaninjo has joined #dri-devel
<alyssa>
lumag: jeez, running a full cts-runner run?!
<enunes>
alyssa: ok... I think I got ppir to kinda work, but it's not pretty, unfortunately it seems that as-is ppir relies on instruction emit to initialize a register so I need to create some dummy node for load_reg otherwise it gets lost
<enunes>
it also relies on func->reg_alloc to know which indices are registers and does some crazy per-component tracking on those indices, this is probably still wrong in my implementation and is likely working by luck
digetx has joined #dri-devel
<enunes>
I'm not sure if I can get rid of that now since everything comes as ssa as in func->ssa_alloc and that per-component tracking is not needed anymore?
<alyssa>
cmarcelo: store_output xfb isn't set by the frontend
<alyssa>
drivers may call nir_io_add_intrinsic_xfb_info if they want that populated
<alyssa>
radeonsi, panfrost, and asahi do that
undvasistas[m] has quit [Quit: Client limit exceeded: 20000]
<alyssa>
but it's but it's not core to how nir xfb works, it's just a driver convenience
<alyssa>
nothing to do with nir_print
<alyssa>
(should nir_print be printing the nir_xfb_info data structure that frontends set and that nir_io_add_intrinsic_xfb_info reads in? possibly!)
<alyssa>
enunes: why does ppir rely on instruction emit initializer a register?
<alyssa>
load_reg is supposed to get lost by the backend, if you're using nir_legacy or chasing helpers
<alyssa>
like, in your emit_intrinsic, if you see a load_reg/store_reg/decl_reg you should just return early and pretend it's not there
<alyssa>
and since ppir actually has an IR and isn't, say, doing RA in NIR .. that should work ok?
<alyssa>
the reg_alloc tracking does indeed sound like it'd be wrong. let me see what it's doing
<alyssa>
could you point me to where that tracking is?
<alyssa>
is that comp->var_nodes?
<alyssa>
oh.. ok
<enunes>
alyssa: because well... it does, it uses the dest of that instruction to initialize this var_nodes structure which contains a reference for who wrote it (last?)
<alyssa>
yeah, I see this now
<alyssa>
ignoring whether var_nodes is a good idea, the easiest way to port this to nir_legacy is to allocate (num_ssa << 2) * sizeof(ppir_node *)
<alyssa>
instead of ((num_reg << 2) + num_ssa) * sizeof(..)
<alyssa>
and removing comp->reg_base (since now it's all mingled, but that's ok)
<alyssa>
and then I think that should work
<enunes>
this <<2 hack is kinda what I have now for it to get it to work :)
<alyssa>
and the funny dance in ppir_node_add_src is just based on the nir_legacy_src instead
<alyssa>
yeah, ok
<alyssa>
it's not ideal but, var_nodes was probably hack #1 ;)
<enunes>
I'm ok with something not pretty to get lima out of your way and then we followup with the needed rework on this
<alyssa>
sure
<alyssa>
there's nothing /wrong/ with bloating up var_nodes, just memory usage of the compiler
<alyssa>
otoh, given lima is gles2 hw and its vertex shaders have a 512 instruction limit.. I am not worried about that personally ;-p
<alyssa>
tbh I don't understand this var_nodes stuff, I guess ppir is some sort of dag-based IR? pretty progressive :'o
<enunes>
I suppose nobody understands this var_nodes stuff, we really need to get rid of it
<alyssa>
heh
<alyssa>
blame goes all the way back to "gallium: add lima driver"
<alyssa>
:~)
<alyssa>
hopefully gpir will be easier, since it's just a direct translate!
heat has quit [Read error: Connection reset by peer]
<enunes>
I still get some crash on ralloc_free sometimes so I guess I will need better hack for var_nodes
heat has joined #dri-devel
<alyssa>
i can eyeball the patch if you push
<austriancoder>
DavidHeidelberg[m]: how does the new flow looks like when I want to change something in gfx-ci/linux (and create an MR.) and wanto tu use the kernel artifacts in mesa ci?
<alyssa>
this index needs to be "<< 2"'d, since the indexing is changed now
<alyssa>
(Probably you want a safe helper to access var_nodes given an ssa def or a register+channel)
tursulin has quit [Ping timeout: 480 seconds]
<alyssa>
(*that* seems more likely to be the crash causer)
<alyssa>
enunes: also, I see you have backend NIR passes that run after legacy_trivialize
<alyssa>
that may or may not be safe
<alyssa>
if that wasn't intentional, I would place the trivialize call after all the duplicate* passes, right at the end before nir_sweep
<alyssa>
(I would need to audit the lima_nir_duplicate_load_* passes to figure out if it's safe to trivialize first... but certainly trivialize was designed to run at the very end)
<enunes>
I put it before our last dce as I saw in the a2xx implementation, now I'm not sure we can run dce after those duplicate passes
<enunes>
I guess I can just put it after everything?
fab has joined #dri-devel
<alyssa>
yeah
<alyssa>
"dce, then duplicate, then trivialize" should be safe
<alyssa>
"dce, then trivialize, then duplicate", I don't know if that's safe, I'd have to check the duplicate impl
<enunes>
I'll put trivialize after everything for now, if shader-db is too bad later I can go back and check if it is worth moving it around
smiles_1111 has quit [Ping timeout: 480 seconds]
Ryback_ has joined #dri-devel
<alyssa>
:+1:
<alyssa>
probably no changes
digetx has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
austriancoder: you do changes in gfx-ci/linux push patches & stuff, tag it, it generates artifacts with the tag and you use the tag in .gitlab-ci/tags.yml in Mesa
<karolherbst>
airlied: f281290005119ddd2dc82e0b7a4cc22551d7fc71 broke some CL atomic stuff :'(
heat has quit [Read error: Connection reset by peer]
<DavidHeidelberg[m]>
austriancoder: there is also open MR which I plan to adapt zo leverage this workflow without rebuilding the Mesa containers (so you could just inject your kernel)
<airlied>
woah did someone write win virlg support, finally
<karolherbst>
airlied: the test breaking is `piglit/bin/cl-program-tester piglit/tests/cl/program/execute/builtin/atomic/atomic_xchg-global.cl`
<karolherbst>
it's weird though as I didn't see anything with the CTS coming up on my other machine...
<karolherbst>
maybe it works with llvm-16?
<karolherbst>
indeed...
<karolherbst>
yeah, so with llvm-16 it works, with llvm-15 it crashes
<karolherbst>
I don't know why that change was made though
<karolherbst>
but in any case, seems some float vs int problem
<karolherbst>
eric_engestrom pinged me on this, because that commit was to be picked for the next 23.1 release
<airlied>
I'll take a look today, though I don't have any llvm15 installs left :-P
<karolherbst>
heh
<eric_engestrom>
airlied: if it helps it also fails on 13 :P
<karolherbst>
I think Dave wanted to say, that all machines got upgraded to fedora 38 already :P
<eric_engestrom>
I know :P
<karolherbst>
I was lazy, so on my laptop there is still fedora 37 running :D
heat has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
<cmarcelo>
alyssa: I wonder what could be the regression zmike is referring to then. anyway I'll check if calling the function just to fill up stuff here shows me something.
fab has quit [Quit: fab]
<alyssa>
cmarcelo: ?
<cmarcelo>
alyssa: nir_print vs xfb. I was assuming there was a regression that caused info to not be there, but maybe that's not the case.
glennk has quit [Read error: Connection reset by peer]