itoral has quit [Remote host closed the connection]
shoffmeister has quit []
lplc has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
yyds has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
jsa has quit []
Mangix has joined #dri-devel
gio has quit []
thaytan has joined #dri-devel
dviola has quit [Quit: WeeChat 4.1.2]
jsa has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.1.2]
vliaskov has quit [Read error: Connection reset by peer]
ashish has joined #dri-devel
ashish has quit [Remote host closed the connection]
jsa has quit []
alyssa has joined #dri-devel
gio has joined #dri-devel
fab has quit [Quit: fab]
aravind has quit [Remote host closed the connection]
yyds has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
yuq825 has quit []
rgallaispou has joined #dri-devel
rgallaispou2 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
aissen has joined #dri-devel
alatiera has joined #dri-devel
kzd has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
aravind has joined #dri-devel
mripard has quit [Quit: mripard]
mripard has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
macslayer has quit []
macslayer has joined #dri-devel
<Company>
so, I want to test my dmabuf reading code
<Company>
for that, I need some reference images/data blobs/whatever, so I can confirm my implementation is actually correct
<Company>
is there a way to get those?
<Company>
just so I can make sure I didn't accidentally swap DRM_FORMAT_XRGB2101010 and DRM_FORMAT_RGBX1010102 and things like that
<dj-death>
afaik it's completely opaque
<Company>
not for the linear variant
<Company>
drm_fourcc.h even tries to document it
<Company>
I could go by those docs, but I'd like to have some external verification
<Company>
I also kinda need that if I want to make sure I write the right code in Vulkan
<dj-death>
must have misunderstood your question then
<dj-death>
I thought you were asking if the dmabuf carries some metadata but its content
<Company>
no
<dj-death>
you want to mmap the dmabuf and do memcmp on it?
<pq>
Company, vivid? Kernel V4L2 test driver.
<Company>
pq: that doesn't have all the formats - and it's V4L2's idea of dmabuf formats, which doesn't cover drm_fourcc.h
<pq>
right
<Company>
they have their own fourccs (dmabufs rock!)
<pq>
Nothing comes to mind. :-/
<pq>
IGT theoretically maybe?
<Company>
I mean, I can just implement something and then wait for someone to file bugs, but that seems like a suboptimal solution
<pq>
That's what I've intended to do with Weston testing and so far never got to it yet.
* Company
has recently been annoyed by dmabuf vs Vulkan vs GL vs GLES all having different descriptions for the same and slightly different formats
<Company>
so I'm not centralizing the code in GTK that handles those
<Company>
and originally I thought I'm just gonna be a genius and write perfect bugfree code, but then it turned out I might not be able to do that
<Company>
so now I'm looking for tests
<gfxstrand>
Few of us can...
kts has joined #dri-devel
<dj-death>
Company: I just found an interesting kind of related drm modifier issue
<dj-death>
one more!!
<Company>
I don't even care about modifiers yet
<Company>
I only know about LINEAR, INVALID, and everything else
<Company>
which goes as DONT_TOUCH
<alyssa>
i go to gfxstrand for all my perfect bugfree code needs
<DemiMarie>
Can nonlinear modifiers be interconverted via a shader?
mripard has quit [Quit: mripard]
mripard has joined #dri-devel
mripard has joined #dri-devel
<dj-death>
DemiMarie: interconverted?
<Company>
DemiMarie: modifiers are about memory layout, which may involve allocating in a specific region of GPU memory, or just tiling/aligning memory - it's a free for all
<Company>
so some of them could probably be conferted with shaders, but I'd go with DONT_TOUCH unless you're driver code
<emersion>
pq: tentative has a helper script for this
<Company>
it has the 8 formats that I already have working
yyds has quit [Remote host closed the connection]
<emersion>
lol
<emersion>
might be able to use pixfmtdb for this but will require some work
<sima>
Company, to add to your fun you also need to test dma-bufs that need the DMA_BUF_SYNC_START/END ioctls
<sima>
and/or implicit fence handling (which the above does for you too)
<mattst88>
dcbaker: what happened with mesa-23.2 stable releases?
<sima>
on top of the format stuff
<sima>
I guess a little debugfs node that you can pass buffer metadata and it gives you a dma-buf fd back would be neat for this ...
<Company>
sima: I just use that all the time, so I'm on the safe side there
<sima>
for implicit sync igt uses vgem
<emersion>
sima: isn't this vgem?
<emersion>
or system dma-heap?
<Company>
sima: currently I use Vulkan to create my dmabufs
<sima>
emersion, only the implicit sync stuff I think
<sima>
Company, yeah but that limits you to what that specific driver supports
<Company>
no
<sima>
unless you aim for lavapipe, which I think supports very little
<Company>
I just stuff it in a VkBuffer
<emersion>
I think system dma-heap would work
<Company>
not even
<sima>
Company, well but who generates the test data then to make sure it's not wrong the same way as your code?
<Company>
vkAllocateMemory() + vkGetMemoryFdKHR()
<Company>
sima: right - that requires something else anyway, because Mesa only knows the common formats - plus most of them aren't writable
<Company>
like, NV12
<sima>
emersion, on x86 at least vgem gives you wc, so no explicit flushing/invalidating needed
<emersion>
oh
<Company>
emersion, sima: speaking of lavapipe, we had a discussion recently about a future with software rendering (for cloud-based desktops etc), and supporting dmabufs on llvmpipe was something that seemed important
<sima>
and yeah I guess adding some code to vgem to fill a buffer with a pattern for a specific format would be useful
<emersion>
Company: should already work
<sima>
we do kinda have the drm format lib already ...
<sima>
DemiMarie, if you know what the modifier does exactly, you should be able to emulate it with a compute shader
<emersion>
right
<Company>
emersion: llvmpipe doesn't do dmabufs - at least not with EGL
pa has quit [Ping timeout: 480 seconds]
hansg has quit [Quit: Leaving]
MrCooper has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
sukrutb has joined #dri-devel
macslayer1 has joined #dri-devel
aswar002_ has joined #dri-devel
MrCooper has joined #dri-devel
Ryback_[WORK] has joined #dri-devel
mattrope has joined #dri-devel
pzanoni` has joined #dri-devel
Company has quit [Quit: Leaving]
kts has quit [Quit: Konversation terminated!]
macslayer has quit [Ping timeout: 480 seconds]
mattrope_ has quit [Ping timeout: 480 seconds]
aswar002 has quit [Ping timeout: 480 seconds]
pzanoni has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
i509vcb has joined #dri-devel
alyssa has quit [Quit: alyssa]
<FL4SHK[m]>
Let's say I've got a GCC backend for my GPU where the GPU specific operations (SIMD) are intrinsics in the GPU. Could a Mesa GPU driver use that GCC backend?
<dcbaker>
mattst88: I happened to them... Let me see what state the branch is in and try to pull something together today
<mattst88>
dcbaker: I don't need it or anything -- I was just curious
<mattst88>
23.3.1 was just released today, so I'm not sure there's much point in 23.2.x stable releases at this point
heat_ has quit [Remote host closed the connection]
<dcbaker>
Yeah, this was just a me issue
<dcbaker>
:(
heat_ has joined #dri-devel
<FL4SHK[m]>
<agd5f> "FL4SHK, mesa already uses LLVM..." <- I'm developing a new GPU and I find GCC easier to write backends for than LLVM.
<FL4SHK[m]>
Is it possible to use GCC instead of LLVM?
<mattst88>
dcbaker: don't worry about it -- you've had a ton of stuff going on
<agd5f>
FL4SHK[m], sure in theory
<FL4SHK[m]>
cool
<dcbaker>
Yeah, I still shouldn't have just let if fall on the floor though
<FL4SHK[m]>
I'll work towards that
sumits_ has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
<DemiMarie>
FL4SHK: Honestly you would be better off writing a native Mesa backend. Mesa is moving away from LLVM because it causes quite a few problems.
<FL4SHK[m]>
oh I see
<FL4SHK[m]>
that's fine with me
tyalie has quit []
<FL4SHK[m]>
Out of curiosity, can you tell me what kind of problems exist?
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
alyssa has joined #dri-devel
cyrinux has quit []
cyrinux has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
biju has quit []
<alyssa>
preemptive nak on new LLVM (or GCC or QBE or whatever) gpu backends in mesa
<alyssa>
amd's grandfathered in but if it were proposed today it'd be a nak from me tbh
<alyssa>
(and amd is moving towards aco anyway)
simon-perretta-img has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> JF]
simon-perretta-img has joined #dri-devel
<airlied>
a gcc backend for a gpu would be the most pointless place to start
<airlied>
shows someone designing a cpu :-P
JohnnyonFlame has joined #dri-devel
iive has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
idr has joined #dri-devel
<FL4SHK[m]>
it really depends on the design of the GPU
<FL4SHK[m]>
if GPUs are a large number of scalar cores, then they're a kind of CPU anyway
<FL4SHK[m]>
I know GPUs are arranged in SIMT configurations
<FL4SHK[m]>
I intended on doing just that
Kayden has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
Peuc has quit [Remote host closed the connection]
Peuc has joined #dri-devel
sravn has joined #dri-devel
<alyssa>
if this is a hobby project only, do what you want & don't let anyone rain on your parade :>
<alyssa>
but for in-tree mesa drivers... anything not-NIR in 2023 is a really hard sell for me
<HdkR>
What about RISC-V GPU?
<mattst88>
IMO, people in this channel spend way too much effort answering questions about speculative/impractical/unrealistic ideas
<kisak>
if the hardware is GLES 3.1 era at least, there's a pretty big carrot to bootstrap Vulkan and get it healthy enough to run Zink to bring up both Vulkan and OpenGL at the same time.
egbert is now known as Guest10365
egbert has joined #dri-devel
Guest10365 has quit [Ping timeout: 480 seconds]
<FL4SHK[m]>
<alyssa> "but for in-tree mesa drivers..." <- I'm happy to make a NIR driver
<agd5f>
I would argue that fixing any deficiencies in LLVM would be a better long term solution as compute and gfx start to converge more, otherwise, you end up writing two compilers which sucks
rasterman has quit [Quit: Gettin' stinky!]
<DemiMarie>
agd5f: The hardware is different and needs a different IR
fab has quit [Quit: fab]
<mattst88>
DemiMarie: seriously? stop.
<airlied>
agd5f: haven't people been trying that for 15 years now :)
<airlied>
maybe fastisel will solve all my problems
<airlied>
I think llvm is fundamentally at odds with being a compiler you'd want to use at runtime esp in gaming scenarios and efforts to change that are very difficult
<airlied>
for compute and offline usecases it likely has a lot better advantages in abiltity to optimise
<airlied>
but I don't think divergence is solved problem
JohnnyonFlame has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
lynxeye has quit [Quit: Leaving.]
<agd5f>
perhaps, but I think a lot of it is NIH. Rather than fixing someone else's project, I'll just write a new one tailored to my specific use case.
mszyprow has joined #dri-devel
<airlied>
I think if I was designing a SIMD type thing I'd go LLVM, for SIMT I think NIR is definitely superior
leo60228 has quit []
leo60228 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
sima is now known as Guest10372
sima has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Guest10372 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<DemiMarie>
mattst88: will do
DemiMarie has left #dri-devel [#dri-devel]
glennk has quit [Ping timeout: 480 seconds]
luben has joined #dri-devel
JohnnyonFlame has joined #dri-devel
crabbedhaloablut has quit []
luben has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
zackr has quit [Remote host closed the connection]