ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
a-865 has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: home]
a-865 has joined #dri-devel
moony has quit [Ping timeout: 480 seconds]
idr has quit [Quit: Leaving]
moony has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
shashanks__ has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
sukrutb has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
<mareko>
agd5f: LLVM seems too bloated to me and evolves too slowly, compile times suck, the lack of proper VMEM clausing has't been resolved for years despite being known by the LLVM team, and it doesn't even support graphics and there is no development and no interest to add it, the other team supports graphics shaders by lowering them in LLPC instead of LLVM, whle Mesa lowers them in NIR; while NIR gets new
<mareko>
passes for gfx regularly, LLVM has exactly 0; don't expect LLVM to get any better, but if we disregard VMEM clauses and some other issues, the GPU performance overall is pretty good
<mareko>
the scope of what LLVM is doing is like 50% of NIR, which is like the backend half of NIR, it just doesn't do enough to be a replacement for NIR
<mareko>
it's just an SSA -> bytecode translator with good late optimizations
<mareko>
while the frontend optimizations for GPUs are non-existent
JohnnyonFlame has quit [Read error: No route to host]
<iive>
when bisecting, llvm is always a huge hurdle because of api changes.
<mareko>
NIR is actually the first mover in the graphics compiler space because it's the first SSA-based compiler that actually caters to graphics
<iive>
Also, I've been away from mesa3d topics for like 5 years, I do remember hoping llvm getting fastisel back then...
<HdkR>
globalisel is the new hotness and it still isn't good enough :)
flynnjiang has joined #dri-devel
<mareko>
LLVM will forever be just a bytecode translator from an ISA-level IR (who will generate it?), the only way to fix LLVM deficiencies is to add the fucking second half of the compiler that's missing there that nobody wants to add
<mareko>
it's a good bytecode translator though, I have to say
oneforall2 has quit [Remote host closed the connection]
<FL4SHK[m]>
HdkR: long time no see
oneforall2 has joined #dri-devel
<HdkR>
uh
<FL4SHK[m]>
Dolphin
<HdkR>
whew
<FL4SHK[m]>
that's where I know your username from
pa has joined #dri-devel
<FL4SHK[m]>
I'm not sure how long it's been
<FL4SHK[m]>
But it's been at least a few years
<HdkR>
I'm always around, just not with Dolphin
<FL4SHK[m]>
ah
<iive>
mareko, let's say that mesa3d decides to move away from llvm. how could that happen. could existing developers handle the task, would it require new developers.
<airlied>
I think it would be quicker to close the NIR gap on compute features than close the LLVM gap on graphics
Jeremy_Rand_Talos has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
bmodem has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
glennk has joined #dri-devel
Duke`` has joined #dri-devel
fab has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
lplc has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
zrusin has joined #dri-devel
zackr has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
crabbedhaloablut has joined #dri-devel
fab has quit [Quit: fab]
jsa has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
macslayer1 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
simon-perretta-img has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
sima has quit [Quit: Leaving]
sima has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
simon-perretta-img has joined #dri-devel
<MrCooper>
I haven't seen even a proposal for replacing llvmpipe, so "Mesa is moving away from LLVM" seems a tad premature
tursulin has joined #dri-devel
rgallaispou1 has quit [Remote host closed the connection]
<pq>
Referring to yesterday's discussion, is there any doc on how dmabuf accepting programs should be tested? Maybe even with some notes on how to do it in a pure software (CI) environment?
yyds_ has joined #dri-devel
hansg has quit [Remote host closed the connection]
yyds has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
csloif^ has quit [Ping timeout: 480 seconds]
csloif^ has joined #dri-devel
Duke`` has joined #dri-devel
Haaninjo has joined #dri-devel
Haaninjo has quit []
glennk has joined #dri-devel
pcercuei has joined #dri-devel
jsa has joined #dri-devel
yyds_ has quit []
yyds has joined #dri-devel
frankbinns has joined #dri-devel
flynnjiang1 has quit []
pixelcluster has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
biju has joined #dri-devel
frankbinns has joined #dri-devel
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
Duke`` has quit [Ping timeout: 480 seconds]
<Company>
pq: when I asked last time, nobody had an option other than "use Mesa if available"
<Company>
the only suggestion was dma_heap, but I don't think that works in CI
Duke`` has joined #dri-devel
<Company>
fwiw, software dmabuf support is high on my wishlist for 3 reasons:
<Company>
1. CI
<Company>
2. unifying codepaths for software rendering (in particular on thn clients and other devices without GPU)
<Company>
3. the ability to allocate dmabuf memory for things like software video decoders or Cairo renderers
<Company>
for example GTK3 could be made do that so it can use linux-dmabuf instead of shm with its Cairo rendering
tobiasjakobi has joined #dri-devel
<Company>
((3) is a smaller issue, because it can be done with Vulkan, and then you even get GPU memory and not just any memory, but still)
bmodem has quit [Ping timeout: 480 seconds]
<pq>
Company, yeah, I'm curious about what all different kinds of dmabuf should be used in tests and where to get those from, given the discussion from yesterday made the point there are subtly different types, some needing more carefuly handling than others.
<sima>
roughly four: dma-buf where you get cached system memory and don't have to do expensive cache management with SYNC_START/END (you should still do), dma-buf with write-combine (because reading from those will suck), dma-buf with cached mmap that does require SYNC_START/END and dma-buf with flat out no mmap
<sima>
at least for mmap
<sima>
add in implicit sync for additional fun, but with the import/export ioctl that should be a lot easier to test (together with getting userspace controlled dma_fence from vgem for testing)
<sima>
note that outside of testing userspace controlled dma_fence are a very bad idea because they might livelock and then timeout, so functionally buggy under memory pressure :-)
<sima>
livelock or deadlock, it depends how you look at it
<sima>
Company, pq ^^
<pq>
sima, I've heard most of those words, but I have no clue at all how to turn those words into code in my tests.
<sima>
yeah, atm not doable, I think adding some "give me a special dma-buf" ioctl to vgem would make sense
<sima>
maybe combined with drm_fourcc.h test pattern generation even
<jenatali>
dj-death: weird, I guess long long is 128 bits in clang's data layout for CL/spir
mszyprow has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
hansg has quit [Quit: Leaving]
pixelcluster has joined #dri-devel
biju has quit []
<dj-death>
Where is meaning of SpvMemoryAccessAlignedMask documented? :)
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
<dj-death>
jenatali: have you fought much with alignment issues?
<jenatali>
Very much yes
<dj-death>
jenatali: generated spirv code has aligment of 1 for SpvOpCopyMemorySized
<dj-death>
jenatali: any tip on that side?
<jenatali>
And the memcpy can't be turned into a struct copy in nir?
simon-perretta-img has quit [Ping timeout: 480 seconds]
<jenatali>
My fight has mainly been getting my backend to handle unaligned things, less about trying to coerce them into being aligned in the first place
<jenatali>
Since we still have to deal with packed structs resulting in unaligned accessess
<dj-death>
ah right
<dj-death>
I packed my struct in the hope things would have the same layout in CL & C
<dj-death>
maybe that was a mistake
<jenatali>
Yes
<jenatali>
Packed structs for whatever reason get alignment of 1 in LLVM
<dj-death>
yep
<dj-death>
I'm seeing that now
<dj-death>
I'm dealing with lots of small values
<dj-death>
like u8
<jenatali>
Sounds like you want load/store vectorization
<dj-death>
yeah
<dj-death>
I'm trying to make all struct a series of u8 that rounds up to u32
<dj-death>
or rather aligns to u32
<jenatali>
Unions?
<dj-death>
no just structs
<dj-death>
like the vertex index ;)
<jenatali>
Right I'm saying could you union it?
<dj-death>
only 33 of them
<dj-death>
no it's more I have lots of small values per each of those elements
<dj-death>
and I'm trying to have a single load carry all the data for each element
<dj-death>
rather then have a u32 field for each value
<jenatali>
Can you just run the vectorizer pass in the compiler?
<dj-death>
yeah
<dj-death>
but I also want to limit bandwidth
<dj-death>
and register space
<jenatali>
Now you're into problems I've not dealt with
<jenatali>
My compiler experience ends at producing an IR
<dj-death>
heh
<dj-death>
well thanks again anyway
<dj-death>
you've put me on the path of solving all my issues so far :)