ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nsneck has quit [Quit: bye]
nsneck has joined #dri-devel
tarceri has quit [Quit: Leaving]
tursulin has quit [Read error: Connection reset by peer]
gawin has quit [Ping timeout: 480 seconds]
<airlied>
jekstrand: in nir is there a way to go from a src argument to a texture instruction and say the argument is directly from a shader_in variable?
<airlied>
even if has gone via some movs
<airlied>
hmm nir_ssa_scalar_chase_movs might be useful I suppose
iive has quit []
<jekstrand>
airlied: Yup, that's the thing
maxzor has quit [Ping timeout: 480 seconds]
tarceri has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
tzimmermann_ has joined #dri-devel
tzimmermann has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
FireBurn has joined #dri-devel
<FireBurn>
Hi, I've a new boot failure on agd5f's drm-next tree
sdutt has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
Company has quit [Quit: Leaving]
shankaru has quit [Read error: Connection reset by peer]
<airlied>
daniels, jenatali : no windows runners are online?
<jenatali>
airlied: try in #freedesktop
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
fxkamd has quit []
fxkamd has joined #dri-devel
fxkamd has quit []
kts has joined #dri-devel
kts has quit []
Duke`` has joined #dri-devel
mszyprow has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
tzimmermann_ has quit []
tzimmermann has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
kts has joined #dri-devel
lemonzest has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
maxzor_ has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<tzimmermann>
mlankhorst, are you going to send out the drm-misc-next PR today? if not NOW, there won't be a drm-misc in this cycle. -rc6 will be on sunday
danvet has joined #dri-devel
mvlad has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
lkw has joined #dri-devel
frieder has joined #dri-devel
ahajda_ has joined #dri-devel
MajorBiscuit has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<daniels>
airlied: please ping alatiera in #freedesktop for that, I have no access to the windows machine
pnowack has joined #dri-devel
maxzor_ has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
lkw_ has joined #dri-devel
lkw_ has quit [Remote host closed the connection]
lkw has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
shsharma has joined #dri-devel
maxzor_ has joined #dri-devel
maxzor_ is now known as maxzor
guru__ has joined #dri-devel
guru_ has quit [Read error: Connection reset by peer]
shsharma is now known as shashanks
pcercuei has joined #dri-devel
tursulin has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
lkw has joined #dri-devel
moony has quit []
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<mlankhorst>
tzimmermann: yes definitely!
hikiko has joined #dri-devel
moony has joined #dri-devel
hansg has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
aissen has joined #dri-devel
<tzimmermann>
mlankhosrt, thanks! if you need one of these dp-helper kconfig fixes, you can add my a-b to the patch
kbingham has joined #dri-devel
<mlankhorst>
those fixups were added by airlied when merging
mbrost_ has joined #dri-devel
zzoon has joined #dri-devel
rasterman has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Thymo has joined #dri-devel
Thymo_ has quit [Ping timeout: 480 seconds]
flacks_ has quit [Quit: Quitter]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
flacks has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
gawin has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
maxzor_ has joined #dri-devel
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<alyssa>
aww that's cute llvmpipe hates dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.36 just like grown up hardware drivers :3
zzoon has quit [Quit: Leaving]
zzoon has joined #dri-devel
kts has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<ccr>
:3
dviola has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
zzoon has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
mbrost_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit []
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
mbrost has joined #dri-devel
jewins has joined #dri-devel
<alyssa>
Kayden: is it premature to merge !15118? I guess nobody on the tegra side has seen it yet.
<alyssa>
On the other hand the entire src/gallium/drivers/tegra directory is wrong and should have been deleted 2 years ago.
<alyssa>
nouveau kmsro would be like 4 lines of code.
<alyssa>
okay like 24 but still
<alyssa>
otoh if we're deleting all of drivers/tegra, that one function doesn't matter
<alyssa>
will drop the patch and assign the intel part
<alyssa>
^to marge
mbrost has quit [Ping timeout: 480 seconds]
<ajax>
daniels: project that lives up to its name! that's delightful.
<ajax>
or... better, can i get required:true checks to repeat uncached if they fail
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
mattrope has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
fxkamd has joined #dri-devel
<daniels>
ajax: it would be nice, yeah; there's a Meson issue which I commented on at some point but it didn't seem like it was going to happen
<daniels>
(in fairness, if you have anything which directly or indirectly depends on .version_compare(), you don't want that to be cached either)
<ajax>
this sounds like taint tracking in perl, a bit
gawin has quit [Ping timeout: 480 seconds]
guru__ has quit []
oneforall2 has joined #dri-devel
<daniels>
ideally without the Perl, but yeah
fxkamd has quit []
Haaninjo has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Duke`` has joined #dri-devel
gawin has joined #dri-devel
rgallaispou has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
shashanks has quit [Remote host closed the connection]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
mlankhorst has joined #dri-devel
frieder has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
shsharma has joined #dri-devel
ybogdano has joined #dri-devel
iive has joined #dri-devel
AndroidC512L has joined #dri-devel
<Kayden>
alyssa: I dunno...it's probably okay to land. If it doesn't work for them, they can revert it
<Kayden>
you had a pretty compelling case that this code would segfault if executed
<gpiccoli>
Hi folks, I have a question about framebuffers / fbdev in general, I'm new in the DRM area. So, I've noticed kernel has a sysrq to show FB in emergency mode, right? So, I've tried used that and the content of the framebuffer is exposed really fast, like a "flicker", then we get back to x11/wayland or whatever graphic output we had previously
<gpiccoli>
I've studied a bit, seems there is a "master" there, which is the wayland/x11 in my example, and this takes back the control of the screen.
<gpiccoli>
I'm working a quite early PoC with regards to showing some graphics in a panic scenario, so my question is: is there some in-kernel way of forcibly "disable" this master device, so I can get it disabled, and then expose the FB output (like in the sysrq) but without losing the fb output so fast?
<gpiccoli>
I'd like to stick with the framebuffer content in such emergency event, "forgetting" the master previously set. Apologies if my terminology is bad =D
<gpiccoli>
(I saw some patches from emersion about a new ioctl to disable some fbdev, but i guess this is orthogonal to my problem)
gouchi has quit [Remote host closed the connection]
<emersion>
the usual way to do that is to talk to logind or seatd
<emersion>
you might be able to do it with root permissions plus some magic ioctls
gouchi has joined #dri-devel
<emersion>
but i don't know off-hand
MajorBiscuit has joined #dri-devel
<rodrigovivi>
airlied: regarding fixups/drm-intel-gt-next.patch... I was going to prepare the latest pull request of drm-intel-next right now... should I pull drm-intel-gt-next into drm-intel-next and fix that locally? so you just get this upcoming pull request from drm-intel-next that would contain both?
<airlied>
rodrigovivi: if that makes things cleaner, please do that
<gpiccoli>
thanks emersion ! Yeah, I'd like a kill_current_master() kernel function or something like that heh
ngcortes has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: to JF? to lunch? wot?]
<jekstrand>
dcbaker: So, I'm starting to try and play around with compute again and trying to remember how to unify the Windows and Linux clang detection again...
<jekstrand>
dcbaker, karolherbst: Or I can just change the hard-coded path to point at my homedir. :p
<karolherbst>
jekstrand: yep
nchery has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
lkw has quit [Remote host closed the connection]
<jekstrand>
Yeah, some equivalent to cc's -DFOO=bar would be really helpful for this
* airlied
wonders if jekstrand will just end up writing clover in C :-P
<karolherbst>
lol
<airlied>
or cl frontends will for ever destined to be written by people more interested in the language they are writing it in than CL :-P
<jekstrand>
airlied: It's tempting...
mclasen has quit [Remote host closed the connection]
<jekstrand>
I also wonder some whether or not it's tractable to just invoke cargo and be done with it
<jekstrand>
I know that's not a good long-term solution
<jekstrand>
But CL might be sufficiently self-contained
nchery has joined #dri-devel
<jekstrand>
Starting from scratch in C does have certain appeal...
<jekstrand>
But I really like rust and wish we could use it
<graphitemaster>
jekstrand, So you know how you wrote that whole blog post about LLVM versions on distributions being a problem and why NIR is so great - well if you depend on Rust ... you open that problem back up again at least for building.
<graphitemaster>
Honestly I wish Rust and LLVM were just more stable. The appeal wears thin when you consider how frail that whole ecosystem is currently.
mclasen has joined #dri-devel
<karolherbst>
graphitemaster: why should the versioning problem with rust be the same as with llvm?
<graphitemaster>
Rust depends on LLVM
<graphitemaster>
Specifically the system installed LLVM
<karolherbst>
graphitemaster: but not the generated binaries
<karolherbst>
you just need a working compiler
<karolherbst>
there are also multiple versions of gcc :p
<karolherbst>
and ever update breaks some code
<graphitemaster>
Correct. Except Rust has a lot of crates that depend on Rust/LLVM at runtime for reflection.
<karolherbst>
then we don't use those
<karolherbst>
although we need that llvm crate anyway
<graphitemaster>
Can be tricky. Rust has the NPM / PIP issue where crates are a dependency hell.
<karolherbst>
yeah
<karolherbst>
I don't really see an alternative though. C is really not a great language and you make soo many mistakes, which just stay irrelevant for most parts
<graphitemaster>
Since it's so easy to use dependencies, it's somewhat antithetical to the sort of packaging and stability that C/C++ programmers expect and even distros expect. There is a lot of friction there already.
<karolherbst>
well, we have to go some path to progress
<karolherbst>
I am also don't convinced that pleasing distributions should be the ultimate goal of open source projects or system libraries
<karolherbst>
if we decide that rust is the best language forward, because of reasons, then they have to figure it out
<graphitemaster>
At work we've already run into LLVM hell because we use Odin as our programming language (you can guess from the website what I work on lol). https://odin-lang.org/ - suffice to say anything but LLVM11 is completely broken and I have a whole in-tree LLVM11 thing I need to do.
<karolherbst>
graphitemaster: yeah, hence using llvm forks is a pita
cworth has quit [Ping timeout: 480 seconds]
<karolherbst>
but also llvm modules is just a lot of work, but that's just because of llvm
<karolherbst>
and everybody accepting that a stable API has pros and cons
<karolherbst>
would be llvm as successful if they would have to maintain stable APIs? I think not
<jekstrand>
graphitemaster: Building with LLVM is fine. Linking against it is tricky.
<karolherbst>
I don't really have anything against llvms API changing, just their build system is hell
<jekstrand>
For OpenCL, though, pulling in LLVM is basically non-optional.
<graphitemaster>
Meanwhile the Odin language creator and I are serious about writing our own middle end HIR and writing our own x86_64 code generator (and C backend) because we're both tired of LLVM.
<graphitemaster>
We figured a 4-6 month period should be enough to get something working lol
<karolherbst>
graphitemaster: yeah, if perf doesn't matter to you then you can do that
<karolherbst>
graphitemaster: ehh... well.. I think you underestimate how much work a compiler is
<karolherbst>
or can be
<karolherbst>
how long did nir take to be somewhat working (in production)
<graphitemaster>
Well perf matters, but Odin has a full inline assembler that just dishes out to nasm so anything performance critical we just write in assembly anyways - but also the language has native vector and matrix types which map easily to SIMD without special loop-vectorization passes
<karolherbst>
I am sure if you write your own compiler, you will spend 90% of your time working on that instead of your frontend
<graphitemaster>
So it's a lot easier than a language like C to write optimization passes for in those regards
<karolherbst>
graphitemaster: if "just write assembly" is your answer, I won't use odin ever :)
<graphitemaster>
:D
<karolherbst>
even for C it's most of the time the path to less performance
<karolherbst>
using assembly I mean
<karolherbst>
compilers outperform developers in terms of perf
<karolherbst>
period
<graphitemaster>
I'm just pointing out there is at least a work around. Ideally it would optimize well. Odin as a language does not have the sort of UB C has so a lot of LLVM optimization passes have to be disabled anyways.
<karolherbst>
graphitemaster: yeah, but if it should optimize well, you can just use llvm :D
<graphitemaster>
Like type punning, strict-aliasing, those sorts of things.
<anholt>
this feels pretty thoroughly off topic at this point.
<karolherbst>
dealing with llvm crapyness requires less time than writing a new compiler
<graphitemaster>
But then neither does MSVC have those because Windows depends on that crap too.
<graphitemaster>
Anyways, yeah this is tangentially related and offtopic. LLVM has been a _pain_
<karolherbst>
and for CL we either write a new C parser (hell no) or just use llvm
<karolherbst>
although at this point we need C++ and CPP as well
<graphitemaster>
Almost every release we're plagued with LLVM issues and I just don't want to see you take on those similar burdens.
<karolherbst>
anyway.. ABI/API breakage is one thing, and normally you can workaround that with so versioning, which a most projects should do
<graphitemaster>
If it can be avoided that is.
<karolherbst>
graphitemaster: we already use llvm
<karolherbst>
sure.. every version the API breaks, so what?
<karolherbst>
needs less time than writing everything ourselves
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst>
at least from a CL or swrast perspective that is
<graphitemaster>
Yeah and it's my understanding that llvmpipe has already been superceded by a newer faster thing and most backend drivers all speak NIR - it seems like LLVMs existence in mesa is a more niche thing
<karolherbst>
graphitemaster: huh? those things are unrelated
<ajax>
no, llvmpipe is still the quasi-fast swrast
<ajax>
swr got retired and lp's seen some work since that closes the gap a bit
<graphitemaster>
I'm just thinking of things that use LLVM inside the mesa ecosystem. Is it more than just llvmpipe and a few obscure drivers?
<karolherbst>
well swr was just a show case for AVX2 really or something
<ajax>
i would consider swapping llvm for something like mir maybe. but i'm definitely not writing my own jit.
<karolherbst>
graphitemaster: radeonsi?
<karolherbst>
atlhough I think that's slowly moving to nir? dunno what's the status here
<ajax>
graphitemaster: some of the weirder compat-gl rendering modes are (optionally) done with llvm, and unusably slow without it
<karolherbst>
graphitemaster: also.. for CL we make use of clang
<karolherbst>
we don't really do llvm stuff
<ajax>
also, lavapip
<ajax>
e
<graphitemaster>
karolherbst, OpenCL does seem like a special hell
<karolherbst>
so we put in some code (clc strings) and convert that to nir through a chain of translations :D
<karolherbst>
graphitemaster: yeah.. well, it's basically just C with minor changes
<karolherbst>
CL also allows spir-v kernels since 2.1, but anyway.. we just translate the llvm ir stuff to spir-v and got a common path
<mattst88>
karolherbst: AFAIU, swr was a closed-source thing with real users that Intel open sourced (and then kind of stopped working on? not sure)
<karolherbst>
mattst88: yeah, might be
<mattst88>
I know the two people that I and a couple others on the Intel Mesa team met with in probably 2015 are no longer at intel
<graphitemaster>
Software rendering is one of those things where performance is never going to be sufficient for real world uses that I'd just write a regular non-optimizing implementation for without a JIT or anything. To be honest I don't really understand the intended use-cases of software rendering other than having a working desktop to download and install working graphics accelerated drivers or for robustness purposes in security-critical
<graphitemaster>
platforms.
<karolherbst>
airlied: sometimes I wonder if we should just rip out llvm targets out of clover :D
<karolherbst>
we don't need it for AMD anymore, or do we?
<graphitemaster>
The latter of which a JIT would not be allowed for anyways because executable memory is off limits and needed by a JIT
<karolherbst>
graphitemaster: sure, and still you need software rendering for some use cases
<karolherbst>
that's not up for debate, we need a fast swrast
<graphitemaster>
Such as?
<karolherbst>
running a desktop on systems without 2d or 3d acceleration
<mattst88>
at least the use cases for swr were around data visualization where you had more vertices than a discrete card could handle
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
<karolherbst>
like for instance on all ampere GPUs if you don't want to use the nvidia driver
<karolherbst>
because we don't have acceleration working there yet
<ajax>
or in a sufficiently dumb virtual machine
<karolherbst>
should I tell users "ohh, don't use your fav desktop, just use twm or something I don't know"
<ajax>
or for testing your app's renderer on a build server that doesn't have a real gpu
<karolherbst>
yeah
<karolherbst>
we could easily come up with 100 reasons we need a good swrast :)
<graphitemaster>
I thin if you're going to build a system with an Ampere GPU but decide not to have graphics acceleration you're a bit of an idiot. What a waste of hardware lol
<karolherbst>
graphitemaster: ?
<ajax>
or any machine where all you have yet is the firmware framebuffer because the driver doesn't exist yet
<karolherbst>
graphitemaster: why do you mix those two use cases
<graphitemaster>
I mean that's what the hardware is designed for.
<karolherbst>
1. build server without a gpu 2. user who got new hardware and just wants to use it
<karolherbst>
graphitemaster: yeah, and?
<ajax>
consider that OSes have releases, and inevitably some new GPU will be released between updates
<karolherbst>
same can happen to intel as well
<ajax>
if your GUI needs GL to work, then until you have a driver _in the release_, you have no GUI for that machine, and cannot even install the OS enough to get the updates that would get that GL driver to you
<karolherbst>
graphitemaster: ehh.. mistread your sentence, but still.. sometimes users have systems and too old software on it
<graphitemaster>
I'm not denying there is valid use cases for software rendering. I'm just saying I think the problem domains are far exaggerated and pathological to begin with.
<ajax>
(yeah yeah kickstart works without a gui, you get the point)
<karolherbst>
graphitemaster: ever used swrast on a 4k screen?
<graphitemaster>
I have 4x 4k screens, I installed the NV driver from the unix portal in a TTY from links
<karolherbst>
and before you complain, that users should do it. Well.. you have to be able to change the settings somehow through the GUI :)
<graphitemaster>
So that should answer your question XD
<karolherbst>
graphitemaster: yeah well.... not all users are werido geeks
<karolherbst>
:P
<graphitemaster>
Fair, touche
<ajax>
perhaps more politely phrased as: that shouldn't need to be a hoop someone should need to jump through.
<karolherbst>
yeah.. and if we need swrast anyway, then we can also make sure it's as fast as possible
<ajax>
it can be done, but it sure is nice not to need to learn how to do that
<karolherbst>
otherwise even FHD would be laggy on some systems (and I am sure it already is)
<graphitemaster>
Also, webbrowsers like Firefox have already have software rendering (WebRender) sw-gl specifically which put things like swr and swrast via llvmpipe to shame.
<graphitemaster>
So it's mostly desktop compositing in that case swrast is used for
<karolherbst>
yeah, and it's not really fast even through we try to make it very fast
<karolherbst>
graphitemaster: but your desktop might also use GL
<karolherbst>
and so are random apps
<karolherbst>
*do
<karolherbst>
like Qt5 and gtk3 already started to use GL for 2d acceleration
<karolherbst>
anyway
<graphitemaster>
I know. It's why long running compute kernels completely stall the desktop on Linux and drive me nuts >_>
<karolherbst>
we need swrast and there is no point discussing it ;)
<graphitemaster>
We need to go backk to the desktop being all software XD
<airlied>
karolherbst: nope it still works, radeonsi for the cl/nir doesn't work yet, some day I'll get to rebasing those patches
<karolherbst>
airlied: ahh
<karolherbst>
shame
<karolherbst>
I'd like to get rid of that llvm code :D
ella-0_ has joined #dri-devel
<ajax>
just port them to aco
<airlied>
ajax: if mir ever added vector support :-P
<karolherbst>
although I think the MR itself is fine
<ajax>
but also, prerequisite
ella-0 has quit [Read error: Connection reset by peer]
shashanks has quit [Ping timeout: 480 seconds]
* karolherbst
should eat something
* airlied
doesn't have a working CL setup on AMD at the moment unfortunately
<karolherbst>
airlied: also what about r600? does it still require LLVM?
<airlied>
yeah r600 CL would also require it
<karolherbst>
shame
gouchi has quit [Quit: Quitte]
<airlied>
I don't feel bad about ripping out r600 CL though
<karolherbst>
yeah.... no idea
<airlied>
I doubt it has many users
<karolherbst>
yeah, I am sure there are like 10
<karolherbst>
maybe disable it and check who complains?
<airlied>
I was adding libclc stuff and was close to ripping out that native stuff
<airlied>
though I'm also just tempted to reboot in C and never ad d it
hansg has quit [Quit: Leaving]
<karolherbst>
completely understandable
<karolherbst>
I also won't care in my rust version :D
neonking has joined #dri-devel
* airlied
is giving rust a chance to get started before I produce a C version :-P
<karolherbst>
:D
<karolherbst>
well atm the only thing missing is really the compiler stuff
<karolherbst>
everything else kind of already works
<airlied>
get back to me when you implement clCloneKernel :-P
<karolherbst>
:D
<karolherbst>
what needs clCloneKernel?
<airlied>
CL3.0 complaince
<karolherbst>
ahh
<karolherbst>
at least I advertise CL3.0 support :D
<karolherbst>
oh well
<karolherbst>
let's see how far I get on Friday wiring up the compiler
<neonking>
good evening peoples o/ (if it's evening by your side)
<neonking>
i wanted to know if there was some expected bugfixes to come soon to mesa-22.0.0-rc2 if someone know about it?
danvet has quit [Ping timeout: 480 seconds]
<neonking>
i'm working on packaging it ^^
<karolherbst>
neonking: what do you mean? it's rc2, and there will be a 22.0 release at some point containing bugfixes
<mmind00>
question regarding drm-misc: commit c0cfbb122275 ("drm/rockchip: dw_hdmi: Do not leave clock enabled in error case") went into mainline via drm-misc-fixes, now another commit aimed for drm-misc-next changes the same area ... what's the best way to solve this?
<Sachiel>
we missed the release on 2022/02/22 :(
<neonking>
karolherbst, i'm not very familiar yet with the mesa release cycles, so i was expecting some 22.0.1 or alike soon
<neonking>
Sachiel, indeed :D
<karolherbst>
neonking: if you are not familiar yet, then I am kind of curious on why you need to package it? mesa gets constantly updated, so...
<Sachiel>
subscribe to the mailing list and you'll get a mail with every rc and release
zf has joined #dri-devel
<neonking>
karolherbst,Sachiel i'm subsribed to the mailing list and waiting for the 22.0.0 final release, i was more curious about when "exactly" to expect that final 22.0.0 release and if it'll require more patching from rc2 ^^
<neonking>
i know delays can vary, but a release of the OS i'm working on is coming soon, hence my current interest in latest mesa
<anholt>
I do know what libepoxy is, having written it. I don't know what you're asking me, though.
<neonking>
anholt, wasn't asking anything, was thanking you for the link to release calendar (what i was asking for) as well as for writing libepoxy which is a nice piece of software
<neonking>
wasn't expecting an answer from you :)
<anholt>
yw
<FLHerne>
Looks like the calendar needs an update though
zf has quit [Ping timeout: 480 seconds]
zf has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
ybogdano has joined #dri-devel
zf has quit []
zf has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
zf_ has joined #dri-devel
zf has quit [Read error: Connection reset by peer]
<jekstrand>
The proxy script might not be a bad intermediate solution for meson...
<karolherbst>
especially given that you execute rustc exactly once per target
<dj-death>
jekstrand: what are you trying to do in rust?
<karolherbst>
dj-death: compiling code I've written :P
<karolherbst>
dj-death: the issue is that we have to mix generated and non generated code
<cheako>
I don't get why you don't just use `/tmp/environment_project` or `./enviornment` and place the variable definition in the file?
<cheako>
You can then include further files.
<cheako>
Why you need more somehow is unexplained.
<karolherbst>
cheako: dcbakers reason is that it's slowing down compilation by a lot
<jekstrand>
We need to be able to bake it all into the arguments we stuff in the Ninja file. Side-band things are fragile at best.
<cheako>
So you won't read the source?
<cheako>
You won't ever open a file because they are side bands?
<jekstrand>
Source files are side-band, yes.
<jekstrand>
But we need to pass things from meson to the source of a file.
<jekstrand>
In particular, we want to include!() things that have been auto-generated and that means they live in some directory set by the user when they did `meson setup/configure`.
<jekstrand>
There's no way to get that path rust currently
pnowack has quit [Quit: pnowack]
<jekstrand>
Yes, we could generate an environment file but that file would end up in the builddir and we're back to the same problem of not knowing where it is.
<karolherbst>
jekstrand: the core issue here is though that's kind of a circular dep issue. The bindings depend on our own definitions of structs (because CL forward declares them and rust doesn't allow that) but if we write out code, we want to make use of CL definitions for random things. So we might get around that issue by writing a core lib with those strust definition without using anything of CL, let the bindings lib depend on that and have an
<karolherbst>
API implementation on top of those two things
<karolherbst>
but I am using CL definitions in the "core" bits for... good reasons
<jekstrand>
karolherbst: There's multiple issues here, I think.
<karolherbst>
like lists of CL objects
<karolherbst>
yeah...
mvlad has quit [Remote host closed the connection]
<jekstrand>
karolherbst: One fairly fundamental one is that when you bindgen something, you need to stick it somewhere in the namespace hierarchy which is defined by folder structure. The include!() is pretty effective for that and, IMO, a lot cleaner than having meson re-arrange your directory structure into something rust friendly in a subdir of your builddir.
<karolherbst>
jekstrand: that's not really an issue
<jekstrand>
Normally, this is handled by running bindgen once and checking the result into your git repo. This is fine if you're writting a wrapper crate around some C library. You only have to update it when you add stuff that uses new features so it's no big deal.
<karolherbst>
I am also bindgen mesa stuff
<karolherbst>
and that lives in its own lib
<jekstrand>
karolherbst: Maybe I'm misunderstanding things then
<karolherbst>
and I just depend on that lib
<jekstrand>
hrm...
<karolherbst>
jekstrand: rust doesn't do forward declarations
<karolherbst>
but CL headers forward declare types
<karolherbst>
so I have to feed types decl into the generated source
<jekstrand>
Ok, I'm clearly missing something then
<karolherbst>
well.. it doens't stop there
<karolherbst>
ICD requires us to put the ICD table as the first field of those types :)
<karolherbst>
worst thing is, that those structs are even refcounted :/
<karolherbst>
it's all a mess
<karolherbst>
I think I came up with the best possible solution from a code perspective, but...
<karolherbst>
I hope I am wrong on that
<jekstrand>
Yeah, reference counting is a mess
<jekstrand>
I wasn't expecting you to use the actual CL struct types. I was expecting a dummy and some unsafe magic
<karolherbst>
check my decl_cl_type macro.....
<karolherbst>
jekstrand: yeah well..
<karolherbst>
that's decl_cl_type
<karolherbst>
I hope that's enough unsafe magic for you :D
<jekstrand>
Why are you using an Arc and your own reference count?
<karolherbst>
for internal references
<karolherbst>
makes things easier
<karolherbst>
the application can free objects
ahajda_ has quit []
<karolherbst>
and our stuff still works
<jekstrand>
double reference counting always freaks me out
<karolherbst>
and I really didn't want to bother with manuel reference counting
<karolherbst>
I was thinking about having one reference count
<karolherbst>
but...
<karolherbst>
like expose the value of Arc to the clients
<karolherbst>
but clients can actually just change the value on a whim
<jekstrand>
wait, what?
<karolherbst>
so I wanted to le the client trash memory if they want to
<karolherbst>
but keep our internals safe
<karolherbst>
jekstrand: yeah....
<karolherbst>
CL has release and retain functions :)
<jekstrand>
Oh...
<jekstrand>
Never mind me, then...
<karolherbst>
:D
<jekstrand>
That's horrifying
<karolherbst>
as I said, I've done my best
<jekstrand>
hehe
<jekstrand>
karolherbst: I do wonder if what we want here is actually a macro or just a generic type
<jekstrand>
karolherbst: You're about to tell me why it has to be a macro. :)
<karolherbst>
because macros are awesome
<jekstrand>
that's not the answer I was looking for. :PP
<karolherbst>
:D
<karolherbst>
generic types are a bit painful in rust
<jekstrand>
I mean, rust macros are pretty awesome...
<karolherbst>
maybe it would be feasible though, somehow
<jekstrand>
The way I would expect this to work is to have a struct CLWrapper which has the reference count and contains an Arc of the type.
<karolherbst>
but I also wanted to get all those impl blocks for free
<karolherbst>
jekstrand: yeah, that's what I do :)
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: I might try to turn that macro into proper generics, but I think there was a reason I did it as a macro later on
<karolherbst>
mhh, I think something with traits was the reason it didn't pan out
<jekstrand>
karolherbst: :-/
<jekstrand>
karolherbst: Handling retain/release is going to be painful no matter what we do but ugh...
<karolherbst>
yeah...
<jekstrand>
karolherbst: It feels to me like it's trying too hard to avoid an extra pointer indirection.
<jekstrand>
What you have now has the advantage of having everything in a single allocaiton but at the cost of weird crazy macros.
<karolherbst>
jekstrand: I don't want to use objects the client can trash
<karolherbst>
jekstrand: well..
<karolherbst>
the macro doesn't hurt anyone
<jekstrand>
It hurts me. :P
<karolherbst>
:D
<karolherbst>
so my idea was to just pass the arc ref around internally, and most of the bits the macro is doing is for convenience
<karolherbst>
I can try to convert it into a generic, but I have to figure out how to do it :) maybe struct _cl_device_id { pub w: CLWrapper<CLDevice>, } could pan out?
<jekstrand>
I'm thinking about it
<jekstrand>
question before I get too far in. I see CLEvent and _cl_event but where is cl_event defined?
<karolherbst>
cl_event is part of the cl headers
<karolherbst>
it's a pointer to _cl_event
<jekstrand>
right
<jekstrand>
because that's not confusing
<karolherbst>
well..
<jekstrand>
Not your fault. Just part of the CL api
<karolherbst>
yep
<karolherbst>
I was just happy having found a solution I can work with and doesn't make implementing CL a pain
<jekstrand>
Yeah
<jekstrand>
Also, any particular reason why you kept clover's api/core split? I never got why that was there in the first place.
<karolherbst>
not sure for clover, but my idea was to put all validation into api, but I might revert splitting it up, not quite sure yet. It made more sense when I started and makes less sense now
<jekstrand>
k
<karolherbst>
in the past I really had two struct declarations
<jekstrand>
I think it does make some sense from an OO POV but I don't like OO :P
<karolherbst>
for each side
<karolherbst>
:D
<karolherbst>
yeah.. for now api/ is like 80% quotes from the spec
<jekstrand>
heh
<jekstrand>
Yeah
<jekstrand>
That might be enough reason to split it, TBH
* jekstrand
forgot how much validation GL/CL have
<karolherbst>
yeah
<karolherbst>
also I think in api/ I want to be less strict with the safe vs unsafe business
<karolherbst>
and core/ should be all safe or so
<jekstrand>
Yeah, that makes sense
AndroidC512L has quit [Read error: Connection reset by peer]
<jekstrand>
Regardless of whether we do a macro or a generic type, I'm kind-of thinking that the _cl_foo belongs in API and not core.
<cmarcelo>
re: build system. wonder if we had the ability to feed a meson target some extra environment variables OR meson would set the "output dir" environment variable for us, it would be sufficient for us. is not a general meson solution but allow people to build stuff without the configure_file() hack.
<cmarcelo>
basically we could do the: include!(concat!(env!("HYPOTHETICAL_MESON_OUTPUT_DIR"), "/path/to/generated.rs"))
<karolherbst>
jekstrand: yeah maybe...
<karolherbst>
but I think both ways feel wrong for one reason
<jekstrand>
heh
<jekstrand>
I think it'll be less wrong if we get away from the macro...
<karolherbst>
maybe
<jekstrand>
The macro is doing this weird dependency loop thing because it's trying so hard to have the CLFoo embedded in the _cl_foo instead of the _cl_foo having an Arc<ClFoo>
<karolherbst>
cmarcelo: sure, and how to feed the env var to rustc?
<cmarcelo>
dcbaker: ^ that would solve things for Mesa (and others) until a general meson solution of automatically creating the include files work.
<karolherbst>
rustc does set OUT_DIR
<cmarcelo>
karolherbst: teach meson to let us give env vars or teach meson to always give that particular env var (since is general enough)... it is a "change meson instead of rustc" solution.
<karolherbst>
cmarcelo: yeah sure.. but ninja doesn't allow us