oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
Namarrgon has quit [Quit: WeeChat 3.7.1]
Namarrgon has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
ppascher has joined #dri-devel
aravind has joined #dri-devel
bmodem has joined #dri-devel
mhenning has quit [Quit: mhenning]
JohnnyonFlame has joined #dri-devel
Guest586 is now known as DrNick
JohnnyonF has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
Duke`` has joined #dri-devel
<tomeu>
jljusten: robclark: not sure what happened to those machines, but during the weekend their network became so flimsy that they are useless
<tomeu>
I have disabled them for now to not block MRs
bgs has joined #dri-devel
kts has joined #dri-devel
tzimmermann has joined #dri-devel
yuq825 has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
dcz_ has joined #dri-devel
danvet has joined #dri-devel
kts has joined #dri-devel
<jljusten>
tomeu: thanks for taking a look at it
fab has quit [Quit: fab]
aknautiy has joined #dri-devel
bgs has quit [Remote host closed the connection]
mvlad has joined #dri-devel
mszyprow has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
rasterman has joined #dri-devel
fab has joined #dri-devel
tursulin has joined #dri-devel
jkrzyszt has joined #dri-devel
frieder has joined #dri-devel
bbrezillon has quit [Quit: WeeChat 3.5]
bbrezillon has joined #dri-devel
lynxeye has joined #dri-devel
sarahwalker has joined #dri-devel
jfalempe has joined #dri-devel
Major_Biscuit has joined #dri-devel
lynxeye has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<tomeu>
narmstrong: do you happen to know what ISA use the Cadence Tensilica VP6 in the mediatek SoCs?
<narmstrong>
tomeu: nop sorry :-/
<tomeu>
narmstrong: maybe somebody else at baylibre would know? from the openamp work
<narmstrong>
tomeu: yes Alexandre Bailon is the one who knows
<tomeu>
thanks, will ask
<MrCooper>
Lyude: per the Git history, amdgpu was merged in 4.2; DC in 4.15, i.e. over 2 years later
lynxeye has joined #dri-devel
mszyprow has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
<MrCooper>
DemiMarie: e.g. amdgpu doesn't clear memory allocated in VRAM by default; it has a AMDGPU_GEM_CREATE_VRAM_CLEARED flag for this though, "please don't leak information to me" :/
slattann has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<tzimmermann>
javierm, FYI a number of easy build issues have been reported against the recent fbdev refactoring. i have patches pending for them. ETA is some time today
<javierm>
tzimmermann: yes, I noticed the robot reporting those and figured out you would look at them since looked fairly trivial
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
devilhorns has joined #dri-devel
slattann has quit []
ahajda_ has joined #dri-devel
Major_Biscuit has quit []
MajorBiscuit has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Daaanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<emersion>
hm, vulkan question: i'm passing a binary VkSemaphore to vkQueueSubmit(), then I'm exporting it as a sync_file
<emersion>
but when i try to re-use it after the VkCommandBuffer is completed, i get this:
<emersion>
> vkQueueSubmit(): pSubmits[1].pSignalSemaphores[1] is signaling VkQueue 0x616000033980[] (VkSemaphore 0xa2eb680000000026[]) that was previously signaled by VkQueue 0x616000033980[] but has not since been waited on by any queue.
<emersion>
afaik exporting the VkSemaphore as a sync_file resets it so i have no way to wait on it after export?
<emersion>
cc jekstrand
<emersion>
everything would be much simpler with timeline semaphores exported to drm_syncobj, but no ext for that… :(
<emersion>
oh, there is no VkSemaphore reset…
<emersion>
hm now i'm confused
<emersion>
"exporting a semaphore payload to a handle with copy transference has the same side effects on the source semaphore’s payload as executing a semaphore wait operation"
<emersion>
so this is a validation layer bug?
yuq825 has left #dri-devel [#dri-devel]
<jekstrand>
emersion: Yeah, that sounds like a validation bug
fxkamd has joined #dri-devel
<emersion>
jekstrand: thanks for confirming, i'll try to dig into that… btw, are you still -1 about a drm_syncobj import/export ext?
<jekstrand>
emersion: Yeah. But it's looking like sync_file export from timelines may happen.
<emersion>
ah, that would be nice
<emersion>
hm, but how would that work?
<emersion>
there's no timeline point supplied?
<jekstrand>
You would have to supply a time point
<emersion>
ah, okay, so not with the existing exts, but with a new ext
<jekstrand>
We'd extend VkSemaphoreGetFdInfoKHR
<emersion>
what's the motivation for sync_file over drm_syncobj?
<jekstrand>
sync_file is definitely needed by Android and always will be. It also retains the option to swap the timeline semaphore implementation out without the client knowing.
<emersion>
hm, i see
<jekstrand>
The more kernel primitives we have to keep working when we switch everything to memory fences, the harder it's going to be.
<emersion>
okay, that makes sense
<emersion>
that ext would already be a huge help
chloekek has joined #dri-devel
<emersion>
then i can import/export sync_file into my own drm_syncobj anyways
<jekstrand>
Yeah
<emersion>
so i take it we should really hold off that new explicit sync wayland ext
<emersion>
for the same reason we don't want a new vulkan ext which uses drm_syncobj
<jekstrand>
🤷
<jekstrand>
It's not at the top of my list, anyway.
<emersion>
now that we have the import/export sync_file ioctls, it's a less perssing matter
<emersion>
well, except for NVIDIA
<jekstrand>
Yeah. The Vulkan over-sync and latency problems are pretty well sorted at this point.
<jekstrand>
I'm solving NVIDIA by replacing their driver stack. :-P
<emersion>
yup, that is the correct answer :P
<jekstrand>
:D
jewins has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
chloekek has quit []
<kisak>
dcbaker / eric_engestrom: how would you feel about formalizing a release schedule for the amber branch? I'd like to suggest at least point release per year, maybe aligned to the first major main release of the year (starting with 23.0.0). It could remain in the 21.3.X format as far as I care.
<kisak>
^one point release per year
<ajax>
one a year feels about right to me
<ajax>
possibly two? fedora does twice a year and tends to update the compiler when it does so there's likely to build fixes on that schedule anyway.
<kisak>
my line of thought was that there might not be enough of a difference in 6 months to warrant two per year.
ppascher has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
Akari has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
tlwoerner_ has quit []
tlwoerner has joined #dri-devel
fab has quit [Quit: fab]
<karolherbst>
jekstrand: btw, I'd really like to merge !19381 this week in order to move radeonsi/zink support further. So if you have some ideas/suggestions on how we should change things to make things more sane.. also still have this sampler workaround for lower_io in my pipeline and no good idea on how to tackle that besides changing the var modes temporarily
<jekstrand>
karolherbst: I kind want to say "fix radeonsi and Zink". :-/
<karolherbst>
yeah.........
<jekstrand>
Zink has a bit of an excuse. I see no reason why radeonsi needs derefs.
<karolherbst>
I think there is this long term plan of moving away from that
<jekstrand>
AFAIK, that's a relic of days gone by when they did everything with derefs because "OMG LLVM"
<karolherbst>
but it still makes it easier when translating to llvm I think?
<jekstrand>
IDK how much I care about "easier when translating to LLVM" if it means different paths in all the state trackers.
<karolherbst>
yeah...
<karolherbst>
but I'm also not really in the mood of fixing radeonsi here as this is probably a huge project on its own
<jekstrand>
IDK if it is or not.
<karolherbst>
though I still think that having split textures/samplers supporting more natively is a good thing, though st/mesa doesn't need it, but rusticl and nine kind of do
<karolherbst>
the deref situation is just... uhguh
<karolherbst>
anyway.. currently texture ops point to image vars, which we don't want to have, so this part should be addressed regardless. Supporting derefs isn't really much of a deal here at this point
ybogdano has joined #dri-devel
<cwabbott>
I don't think there's any good reason for radeonsi to use derefs for textures/samplers anymore
<cwabbott>
there might've been the idea at one point to transform them directly into llvm GEP instructions, but that never came to pass
<cwabbott>
it probably wouldn't be that difficult to switch, since the current lowering code just converts it to indices internally, but it might conflict with efforts to move that lowering to NIR
<jekstrand>
karolherbst: My only real gripe is with the last patch.
<jekstrand>
karolherbst: How do addresses even make sense for image variables? They don't have a size.
<karolherbst>
ahh right...
<karolherbst>
they don't, but the address has
<jekstrand>
karolherbst: I think I'd rather we create a new nir_variable that's a "normal" uniform/input but which has an actual type.
<karolherbst>
so the thing I needed to solve is, that because I'm lowering those things, I actually need to know the index
<karolherbst>
which is hard if I only get the deref chain
<karolherbst>
I really only needed the indirect/direct binding slot so I can load data from an array
<karolherbst>
(and we might need a solution for this once we do function calls and pass image/sampler vars around)
<jenatali>
jekstrand: Am I right based on your comments on the WSI change that the overall direction seems roughly okay?
<emersion>
vsyrjala: needs a review
<jekstrand>
vsyrjala: The only person I can think of who's remotely likely to review that is ajax
<karolherbst>
jekstrand: alternatively I could ignore we ever get indirects and just fetch the variable and pull the constant binding out of it...
<jekstrand>
karolherbst: Yeah, that may be a valid thing to do in CL, honestly.
<jekstrand>
karolherbst: We shouldn't get indirects until we get real functions.
<jenatali>
CL doesn't support indirects on textures or samplers, yeah
<karolherbst>
okay, then let's postpone it into the future and hope radeonsi figures out getting rid of deres until then :P
<karolherbst>
jenatali: functions though
<karolherbst>
or not?
<jenatali>
True, you can pass textures and samplers into functions
<karolherbst>
like you can pass in image vars into other functions and then you have an indirect
<jenatali>
I ignored that because we inline 'em all and then copy prop figures it out
Terman has joined #dri-devel
<karolherbst>
same
<karolherbst>
but we don't want to keep it
<karolherbst>
my first step would be to not inline all of libclc and see if that's good enough (tm)
<jenatali>
Yeah
<karolherbst>
so I'm not tackling those issues
<jekstrand>
karolherbst: I think we can reasonably assume that "don't use sampler derefs" can be a prereq for real functions in the back-end. One of these problems is harder than the other. (-:
<jenatali>
Ooh... I'm realizing that when we support SM6.6 I can get rid of all of the nonsense around having to manifest texture vars with the correct types...
Company has joined #dri-devel
<jenatali>
And I can just manifest them at the call site. That will be nice...
<jekstrand>
jenatali: Uh, mostly. I still don't like the dozen-only punch-through but I also don't have a better plan.
<karolherbst>
jekstrand: yeah.. just radeonsi is probably the easiest driver to implement function calls on 🙃
<karolherbst>
maybe llvmpipe as well
<jekstrand>
karolherbst: So they can do a tiny bit of extra work. :P
<karolherbst>
:D
<jenatali>
jekstrand: Fair. The only thing I thought of would be to add more escape hatches from common WSI into driver-specific WSI, and then it can live in dzn instead of in the win32 WSI
<jenatali>
But honestly any other Windows drivers might want a DXGI swapchain thing even if they're not dzn... NVIDIA uses that in their Vulkan drivers on Windows to be able to do HDR
<jekstrand>
jenatali: IDK if those escape hatches would be better or not.
<jekstrand>
jenatali: Yeah, I think we'll want DXGI swapchains for other drivers eventually. It's just not clear what that looks like until someone types it up.
<jekstrand>
So doing the easy thing for dozen may be the right call for now, even if we do have to hold our noses a bit.
<jenatali>
Yep, makes sense. Sounds good, thanks :)
fab has joined #dri-devel
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
Duke`` has joined #dri-devel
frieder has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
columbarius has joined #dri-devel
heat has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jessica_24>
hey robclark, danvet, emersion: Dmitry made a few suggestions on the solid fill RFC, particularly an alternate implementation introducing a color_fill_blob struct (https://patchwork.freedesktop.org/patch/509236/?series=110282&rev=1#comment_918450). I think these are reasonable changes, but wanted to run it by you first since it would involve
<jessica_24>
changing the DRM uapi.... any thoughts on this?
nchery has joined #dri-devel
<emersion>
jessica_24: modifiers doesn't make sense to me
<emersion>
pixel_format sounds overkill
<emersion>
one u32 for RGBA channels should be enough
<danvet>
hm pq not around, but yeah you need to chat with pq and emersion for this I think
aravind has quit [Ping timeout: 480 seconds]
<emersion>
is what we've concluded in the wayland-protocols work
<emersion>
jessica_24: i'll try to fidn time to reply to this tomorrow, please ping me again (along with pekka) if i forget
<jessica_24>
sg, thanks!
pochu has quit [Quit: leaving]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
gawin has joined #dri-devel
iive has joined #dri-devel
<gawin>
In current gitlab plan is it possible to make a sticky issue?
sarahwalker has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
* jekstrand
really wishes visual studio supported statement expressions....
mvlad has quit [Remote host closed the connection]
<jekstrand>
I could work around it but that would require TLS. :-/
<jenatali>
Why do you need TLS to work around statement expressions? O.o
<jekstrand>
I want NIR_PASS to return a boolean
<jekstrand>
But it's currently a do { } while(0)
<jekstrand>
If I could replace that with a statement expression, I could make it return something.
<jenatali>
Ah
<jekstrand>
I could work around it by having a bit of TLS somewhere for nir_last_pass_result and doing (do { ... nir_last_pass_result = r} while(0), last_pass_result)
<jekstrand>
At least I think that can work.
<jekstrand>
But it's super ugly and means TLS and just no.
<jenatali>
Yeah, feel free to make that the MSVC version if you have to
<jekstrand>
I think I'm just going to make my own wrapper macros in NAK that do what I need.
elongbug has quit [Remote host closed the connection]
<jekstrand>
It's what we did for Intel and it works well enough.
elongbug has joined #dri-devel
devilhorns has quit []
Akari has joined #dri-devel
apinheiro has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
vliaskov has quit [Remote host closed the connection]
znullptr[m] has quit [Write error: connection closed]
gallo[m] has quit [Write error: connection closed]
martijnbraam has quit [Write error: connection closed]
r[m] has quit [Write error: connection closed]
Guest603 has quit [Write error: connection closed]
underpantsgnome[m] has quit [Write error: connection closed]
x512[m] has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
Anson[m] has quit [Write error: connection closed]
ramacassis[m] has quit [Write error: connection closed]
masush5[m] has quit [Write error: connection closed]
naheemsays[m] has quit [Write error: connection closed]
kunal10710[m] has quit [Write error: connection closed]
ella-0[m] has quit [Write error: connection closed]
PiGLDN[m] has quit [Write error: connection closed]
Labnan[m] has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
DemiMarie has quit [Write error: connection closed]
pushqrdx[m] has quit [Write error: connection closed]
Vin[m] has quit [Write error: connection closed]
EricCurtin[m] has quit [Write error: connection closed]
DavidHeidelberg[m] has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
mairacanal[m] has quit [Write error: connection closed]
cmeissl[m] has quit [Write error: connection closed]
undvasistas[m] has quit [Write error: connection closed]
Guest617 has quit [Write error: connection closed]
nyorain[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
reactormonk[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
jekstrand[m] has quit [Write error: connection closed]
robertfoss[m] has quit [Write error: connection closed]
Ella[m] has quit [Write error: connection closed]
knr has quit [Write error: connection closed]
mripard has quit [Write error: connection closed]
MatrixTravelerbot[m]1 has quit [Write error: connection closed]
michael5050[m] has quit [Write error: connection closed]
LaughingMan[m] has quit [Write error: connection closed]
kallisti5[m] has quit [Write error: connection closed]
bluepqnuin has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
viciouss[m] has quit [Write error: connection closed]
ralf1307[theythem][m] has quit [Write error: connection closed]
frytaped[m] has quit [Write error: connection closed]
Newbyte has quit [Write error: connection closed]
Tooniis[m] has quit [Write error: connection closed]
cleverca22[m] has quit [Write error: connection closed]
Jean[m]1 has quit [Write error: connection closed]
aura[m] has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
moben[m] has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
eyearesee has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
dcbaker has quit [Write error: connection closed]
neobrain[m] has quit [Write error: connection closed]
Grillo[m] has quit [Write error: connection closed]
dafna33[m] has quit [Write error: connection closed]
Soroush has quit [Write error: connection closed]
gdevi has quit [Write error: connection closed]
Strit[m] has quit [Write error: connection closed]
cwfitzgerald[m] has quit [Write error: connection closed]
arisu has quit [Write error: connection closed]
bylaws has quit [Write error: connection closed]
hch12907 has quit [Write error: connection closed]
tomba has quit [Write error: connection closed]
tleydxdy has quit [Write error: connection closed]
sigmoidfunc[m] has quit [Write error: connection closed]
T_UNIX has quit [Write error: connection closed]
Nirvin[m] has quit [Write error: connection closed]
onox[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
kunal_1072002[m] has quit [Write error: connection closed]
kunal_10185[m] has quit [Write error: connection closed]
JosExpsito[m] has quit [Write error: connection closed]
jasuarez has quit [Write error: connection closed]
jenatali has quit [Write error: connection closed]
doras has quit [Write error: connection closed]
egalli has quit [Write error: connection closed]
AlexisHernndezGuzmn[m] has quit [Write error: connection closed]
zzoon[m] has quit [Write error: connection closed]
Eighth_Doctor has quit [Write error: connection closed]
Andy[m]1 has quit [Write error: connection closed]
sjfricke[m] has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
Mis012[m] has quit [Write error: connection closed]
KunalAgarwal[m][m] has quit [Write error: connection closed]
Weiss-Fder[m] has quit [Write error: connection closed]
danylo has quit [Write error: connection closed]
DrNick has quit [Write error: connection closed]
chema has quit [Write error: connection closed]
Wallbraker[m] has quit [Write error: connection closed]
tintou has quit [Write error: connection closed]
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
Wallbraker[m] has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<vsyrjala>
does someone know where one can report bugs against the steam vulkan layer?
<karolherbst>
jekstrand: fixed !19381 :) still need a review on "nir/lower_cl_images: support keeping derefs" though
<vsyrjala>
forgot i already commented on the 10bpc bug there long ago
<vsyrjala>
argh. stupid browser had me signed in with the wrong account. oh well, i guess that won't matter in the end
ngcortes has joined #dri-devel
<danvet>
jessica_24, forgot to mention, where's the igt changes and userspace? generally best to link those in either cover letter or the patch that adds the uapi
<jessica_24>
danvet, I'm planning to submit the IGT changes once the solid fill patch series gets out of the RFC stage
<karolherbst>
yeah.. best to do things 1:1 as rusticl, otherwise things are really edge and complicated. Rust doesn't allow you to mix and match build + src dirs. The official way is to include! files by paths, which... is terrible
<karolherbst>
nope
<karolherbst>
have to include the real type in the bindings header
<jekstrand>
I guess that means I need nir.h...
<karolherbst>
yeah
<jekstrand>
I do need it eventually anyway
<mhenning>
a hack I've used before is to just declare an empty struct if you only need pointers to the type
arisu has joined #dri-devel
Andy[m]1 has joined #dri-devel
Grillo[m] has joined #dri-devel
aura[m] has joined #dri-devel
bluepqnuin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
dcbaker has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest773 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
EricCurtin[m] has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gallo[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest790 has joined #dri-devel
halfline[m] has joined #dri-devel
<mhenning>
(the hack is wrong, but can work while filling things in)
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
Jean[m]1 has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
Nirvin[m] has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest797
alyssa has joined #dri-devel
<alyssa>
dcbaker: Why don't we use SPDX?
<alyssa>
I mean, if it's good enough for the kernel, surely it's good enough for us?
<jekstrand>
Some drivers do
<jekstrand>
IDK why we've not switched tree-wie.
<jekstrand>
*wide
<jekstrand>
I think dcbaker tried to switch us at one point
<alyssa>
I'm in favour but I am not a lawyer
<jekstrand>
Ok, it's building now but not linking. Woo
<alyssa>
(and while I can switch Asahi, I guess I'd have to find out whether Collabora would be ok switching panfrost)
<alyssa>
(of which I own very little at this point)
<alyssa>
(Though definitely nonzero)
Guest773 is now known as DrNick
iive has quit [Quit: They came for me...]
<alyssa>
tomeu: Cadence used Xtensa at one point, try that?
<jekstrand>
/home/jason/projects/mesa/nak/_build/../src/nouveau/vulkan/nvk_shader.c:723: undefined reference to `nak_compile_shader'
<alyssa>
(I think Cadence owns Xtensa.)
<alyssa>
jekstrand: all references in Mesa must be defined, NAK
<jekstrand>
:P
<alyssa>
tomeu: More to the point Tensilica built Xtensa, and Cadence owns Xtensa by way of acquiring Tensilica
<alyssa>
so if there's a funny ISA in a Tensilica core... the obvious choice is Xtensa
<jekstrand>
hrm...
<jekstrand>
my function is `pub extern "C" fn foo...`
<jekstrand>
Why isn't it showing up as a symbol?
<jekstrand>
Aha! no_mangle
<karolherbst>
#[no_mangle]
<karolherbst>
yeah..
<jekstrand>
Hello from rust!
<jekstrand>
Ok, we're off and cooking now.
<karolherbst>
have fun :)
<karolherbst>
the rustification of mesa began and it can't be stopped anymore now! 🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀
<jekstrand>
🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀
<alyssa>
jekstrand: Someone is having fun :-D
Haaninjo has quit [Quit: Ex-Chat]
<jenatali>
So what's being written in rust now?
<karolherbst>
nak
nchery has quit [Ping timeout: 480 seconds]
<jenatali>
Is that a compiler?
<karolherbst>
yeah
<karolherbst>
for nvk
<jenatali>
Cool
<karolherbst>
nak nak, it'll get a duck for a mascot (I hope)
rasterman has joined #dri-devel
<alyssa>
jenatali: But it won't be merged, too many anti-Rustaceans will nak
<jenatali>
:P
* jekstrand
is hoping to entice anholt to work on NAK by writing it in Rust.
* airlied
wonders how rusty nir will get in the process
<jekstrand>
I'm planning to keep it pretty clean
<jekstrand>
I'll need block and instruction iterators and maybe a few helpers like src_is_const() but that *should* be about it.
<airlied>
can we just move instructions to arrays :)
<jekstrand>
Uh, no.
<airlied>
kill all the linked lists :-P
<jekstrand>
NIR is never going to not use linked lists
<jekstrand>
That conversion would be near impossible
<karolherbst>
you can modify linked list from rust just fine :P
<airlied>
karolherbst: you can, but really should you :-)
<karolherbst>
though I've dropped that kind of code :D
<karolherbst>
but I did it in the past
<karolherbst>
it was awesome
<jekstrand>
"awesome"
<alyssa>
jekstrand: like your kompiler
<jekstrand>
alyssa: Hey, now!
<karolherbst>
:D
<alyssa>
did I mispell something
<karolherbst>
I wrote nir passes in rust :3
<karolherbst>
best code ever
<karolherbst>
sadly jekstrand was against it (I'm still sad about that)
<mareko>
the phrase "but that *should* be about it" never ends well
<alyssa>
mareko: +1
<airlied>
lols
<karolherbst>
nir will be rewritten in rust by the end of next year ❤️
<jekstrand>
We shall see. :)
<mareko>
I'll just fix one driver and that will be it.
<karolherbst>
zmike was actually right, nvk is using Nir 2.0
<mareko>
10 years later: ...
<jekstrand>
If this whole thing gets too insane, I'll abandon Rust and go back to C. Should have a decent sense for that in a week or two.
<anholt>
jekstrand: very interested in working on a nak if that's "nv compiler in rust." but also you see my rate of free time projects these days.
<mareko>
C gods are watching
nchery has joined #dri-devel
<karolherbst>
jekstrand: hhehehehehe... you won't
<jekstrand>
karolherbst: I think you underestimate my pragmatism
mszyprow has quit [Ping timeout: 480 seconds]
<karolherbst>
I think you underestimate how pragmatic I was with rusticl
<karolherbst>
not writing C was the pragmatic way out
heat has quit [Remote host closed the connection]
<jekstrand>
I don't hate C as much as you do
<karolherbst>
maybe
<mareko>
let's fork Mesa into two and call them CMesa and RustMess
<emersion>
lol
heat has joined #dri-devel
<emersion>
would be nice actually
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<alyssa>
mareko: no more svga in my Mesa tree? i'm in
gawin has quit [Quit: Konversation terminated!]
<jekstrand>
Ok, I think it's enough rusty fun for one day. Resuming tomorrow.