ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nchery is now known as Guest866
nchery has joined #dri-devel
Guest866 has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
stuart has quit []
ngcortes has quit [Remote host closed the connection]
icecream95 has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
cef has quit [Quit: Zoom!]
rexbcchen_ has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
rexbcchen has quit [Ping timeout: 480 seconds]
linearcannon has joined #dri-devel
<airlied>
karolherbst: with a tree full of hacks, I've gotten a very simple image write test to pass on clover/aco
mbrost_ has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
kts has joined #dri-devel
kchibisov has quit [Read error: Connection reset by peer]
kchibisov has joined #dri-devel
sdutt has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
heat has quit [Remote host closed the connection]
janesma has quit [Quit: Leaving]
mbrost has joined #dri-devel
Daanct12 has joined #dri-devel
cef has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
nchery has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Daanct12 has joined #dri-devel
bmodem has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
karolherbst has joined #dri-devel
sarnex has quit [Read error: No route to host]
sarnex has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
Duke`` has joined #dri-devel
LexSfX has quit []
tzimmermann has joined #dri-devel
hch12907_ has joined #dri-devel
danvet has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
hch12907_ has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
mbrost has joined #dri-devel
LexSfX has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
Haaninjo has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
<bluepenquin>
Hi, I'm trying to bisect to find a regression but building fails with `/usr/include/directx/d3d12video.h:1086:27: error: ‘NumTexture2Ds’ is not a type`, any idea? main/c4cec842315313a24342d1d9a4dbd4ad11fbdd6c (HEAD)
<MrCooper>
feaneron: authentication is only required with /dev/dri/card* (and even then not with DRM master), not with /dev/dri/render*; so why iris doesn't work with the latter remains a mystery
lynxeye has joined #dri-devel
adavy has joined #dri-devel
rasterman has joined #dri-devel
i-garrison has joined #dri-devel
jkrzyszt has joined #dri-devel
lemonzest has joined #dri-devel
ahajda has joined #dri-devel
pcercuei has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.4]
MajorBiscuit has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
ahajda_ has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
sdutt_ has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
<dj-death>
danylo: I was hoping to drop the cs argument from the trace points
<dj-death>
danylo: for Anv/Iris it's always the same, and we can get it back from the u_trace struct
<danylo>
dj-death: But it's not true for Turnip
<dj-death>
yeah, just saw that :)
<danylo>
It's should be useful only for tilers
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
mnadrian has quit [Ping timeout: 480 seconds]
lumag_ has quit [Remote host closed the connection]
<jekstrand>
Does gallium have any sort of a surface cache? Asking for a friend.
lumag_ has quit [Ping timeout: 480 seconds]
<jekstrand>
Specifically, to cache the result of create_surface
<jekstrand>
Sounds like something Zink might like
<alyssa>
jekstrand: No, I don't think so. create_surface is expected to be cheap.
<jekstrand>
:-/
Duke`` has joined #dri-devel
Peuc has quit [Quit: Peuc]
Peuc has joined #dri-devel
whald has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<alyssa>
anholt: let's play count the (preexisting) bugs !16437 has uncovered
<alyssa>
decl_reg vec3 64 r0
<alyssa>
decl_reg vec3 64 r1
<alyssa>
but here's problems #1 and #2
<bbrezillon>
jekstrand: hm, I think I got some vk_sync expections wrong when implementing the ID3D12Fence wrapper. So, ID3D12Fence is basically a timeline-sync, but, AFAICT, it can also do binary (we can reset the fence and multi-wait is supported as well). The thing is, I'm not quite sure the vk_semaphore wrapper works as expected, unless I use the vk_sync_binary implementation to emulate
<bbrezillon>
binary syncs over timeline ones. Looks like the sync object is not explicitly reset after a wait in that case
<bbrezillon>
to sum-up, when I use dzn_sync_type for binary syncs, I think I end in a case where the vk_semaphore only works once, and once it's been signaled, it stays signaled forever. I suspect that's because I shouldn't declare dzn_sync_type as supporting the binary model, but I'd like to be sure I'm not missing something
<alyssa>
we're up to at least 3, i think
<jekstrand>
bbrezillon: I don't think you're missing anything.
<jekstrand>
bbrezillon: I'm not sure how binary D3D12Fence works. It may be that it can be made to work as-is but it's not obvious to me that it can.
<jekstrand>
bbrezillon: If not, just throw a vk_sync_binary around it and move on
<jekstrand>
That's what vk_sync_binary is for
<jekstrand>
bbrezillon: It really only matters if we care about fence/semaphore sharing of binary things
<bbrezillon>
well, we can signal any value we want, so the binary implementation was just using 0 an 1, and the reset was implemented as a signal(0)
<jekstrand>
bbrezillon: Right... But there's no good way to pipeline that. So it works ok for fences where you have an explicit reset but there's no way to make it work for semaphores.
<bbrezillon>
exactly
<bbrezillon>
I'd need to know what the sync is used for
<jekstrand>
bbrezillon: You could have a vk_sync_type which exports binary but not GPU_WAIT
<jekstrand>
But I don't really see a point
<jekstrand>
Shared fences are the least interesting of the sharable objects
<bbrezillon>
or some sort of RESET_AFTER_WAIT flag, but I'm fine with the binary_sync wrapper ;)
<jekstrand>
:)
<jekstrand>
Anyone want to help me get lavapipe built on Windows?
<jekstrand>
I'm getting lots of "mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in liblavapipe_st.a"
<dcbaker>
bbrezillon: that's what I was thinking too
<jekstrand>
worth a try
<anholt>
alyssa: I would recommend giving a little bit of a readme in there of how to use it? other than that, I'm +1 for just add in a tool like that.
<jekstrand>
bbrezillon: Seems to have done the trick. Thanks!
<jekstrand>
Now to see why vkcube doesn't work
jkrzyszt has quit [Ping timeout: 480 seconds]
<alyssa>
anholt: sure, happy to add documentation for that. more making sure it's kosher given the function entrypoints etc
<jekstrand>
And... now to build everything for x64 instead of x86...
<jekstrand>
*sigh*
AndrewR has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
AndrewR has joined #dri-devel
* jekstrand
has lavapipe gears!
<alyssa>
Woo!
Duke`` has joined #dri-devel
<jekstrand>
dcbaker: Does meson have a concept of functions or subroutines?
<alyssa>
jekstrand: you're in too deep
<jekstrand>
dcbaker: Wanting to wrap the ICD stuff
<jekstrand>
We want --use-backslash whenever we're targetting windows
<dcbaker>
jekstrand: user defined functions? no, that's an explicit design decision
<dcbaker>
which part of the ICD stuff?
<jekstrand>
dcbaker: The ICD generator that calls vk_icd_gen.py
<jekstrand>
dcbaker: Currently, every caller is hand-rolling a bunch of stuff and that's not great
<jekstrand>
It's all the same except for the version to embed in the json file and the .so name.
<jekstrand>
except it's not because radv has windows fixes no one else has
<jekstrand>
dcbaker: It doesn't even need to be a full function. Just a thing where i can define a custom generator to call later
<dcbaker>
jekstrand: we've been talking about custom_target templates which would probably solve that issue
<dcbaker>
I've also thought about something like python's function `partials`
<dcbaker>
This is a known problem, it's just a hard problem to solve
<clever>
marex: at a glance, it seems to be 2 problems, 1: the v3d driver is issuing ioctl's to an amdgpu card, 2: the amdgpu driver isnt validating the inputs
<clever>
airlied: yep!
<airlied>
yeah 2 definitely needs to be fixed there
<clever>
yep, it could potentially be a security problem
<clever>
checking the os packages, amdgpu is part of the kernel source tree
mbrost has quit [Remote host closed the connection]
<clever>
airlied: gist updated again, amdgpu_cs_ioctl was too long to copy/paste out of the objdump, so i just shoved the entire thing (43mb) into the gist
<clever>
that may have made github upset...
<clever>
yeah, it doesnt like a 43mb file being uploaded, lol
Daanct12 has quit [Remote host closed the connection]
<airlied>
okay it kills my 5.17.5 kernel
<feaneron>
if i use a gbm_surface through EGLSurface, does that mean i cannot use functions like gbm_surface_lock_front_buffer() and gbm_surface_release_buffer() ?
<clever>
WARNING! Modules path isn't set, but is needed to parse this symbol
<feaneron>
if i create a gbm_device from /dev/dri/renderD128, egl returns failure for many functions, but never crashes
<clever>
airlied: it faulted after amdgpu_ras_intr_triggered() but before printk_ratelimit(), and amdgpu_cs_parser_init() was inlined, cant make out much more from reading asm by hand, to ghidra!
<airlied>
I should be able to figure out how to get more info here
<clever>
ioctl(6, DRM_IOCTL_EXYNOS_GEM_GET or DRM_IOCTL_PANFROST_GET_PARAM or DRM_IOCTL_QXL_GETPARAM or DRM_IOCTL_TEGRA_SYNCPT_WAIT or DRM_IOCTL_V3D_GET_PARAM or DRM_IOCTL_VC4_MMAP_BO <unfinished ...>) = ?
<clever>
what strace reported
<clever>
given that i was using the v3d userland driver, DRM_IOCTL_V3D_GET_PARAM fits best
<airlied>
yeah it's just an ioctl full of garbage
<airlied>
as far as amdgpu is concerend it shouldn't trust any of it
<clever>
its just starting from 0, so there is a high chance of overlap with amdgpu
<clever>
#define DRM_AMDGPU_CS 0x04
<clever>
#define DRM_IOCTL_AMDGPU_CS DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_CS, union drm_amdgpu_cs)
<clever>
airlied: and bingo, DRM_V3D_GET_PARAM and DRM_IOCTL_AMDGPU_CS are the same ioctl#!
<clever>
so amdgpu is expecting a drm_amdgpu_cs, but mesa gave it a drm_v3d_get_param
<clever>
drm_v3d_get_param contains a 32bit, 32bit, and 64bit int
jfalempe has quit [Quit: Leaving]
<clever>
drm_amdgpu_cs is a union between several larger structures, a 32/32/32/32/64 input, and a 64bit output
<clever>
airlied: at the simplest level, this should immedaitely fail, because the userland didnt supply something big enough to be a valid union drm_amdgpu_cs
lumag_ has joined #dri-devel
<airlied>
we don't trust userspace length either, so things get 0 padded
pendingchaos_ is now known as pendingchaos
<clever>
and that padding is likely where the null-ptr came from
<clever>
amdgpu_cs_ioctl calls amdgpu_cs_parser_init which calls amdgpu_job_alloc
<clever>
and passes it the addr of the job pointer
<clever>
so you somehow used the job before allocating it
<airlied>
yeah nchunks = 0 causes lots of things to fail
<airlied>
but without failing properly
<clever>
this feels like the userland should be telling the kernel, "yes i know your amdgpu" before it can do anything
<clever>
just to prevent a v3d client from talking to a amdgpu driver
<anholt>
the kernel interface should already be fuzzed. and, if userspace wants to ignore the kernel telling it what driver it is talking to, you can't really stop them.
<clever>
anholt: then how was i able to trigger a null-pointer in my amdgpu driver?
<clever>
did the fuzzing miss it?
<anholt>
the kernel probably wasn't fuzzed, which is a problem.
<clever>
and why is the v3d client in mesa talking to an amdgpu driver
<jekstrand>
Is there a way to allocate a dma-buf without opening a DRM node?
ahajda_ has joined #dri-devel
<jekstrand>
I guess there's DRM_IOCTL_MODE_CREATE_DUMB
<jekstrand>
I want to test if my new dma-buf ioctls exist without the VkDevice
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
apinheiro has joined #dri-devel
ahajda__ has joined #dri-devel
ahajda_ has quit [Read error: Connection reset by peer]
ahajda__ has quit []
sdutt has quit []
sdutt has joined #dri-devel
X512 has quit [Quit: Vision[]: i've been blurred!]
mszyprow has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
tursulin has quit [Remote host closed the connection]
simon-perretta-img_ has joined #dri-devel
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
pcercuei has quit [Quit: dodo]
rkanwal has quit [Read error: Connection reset by peer]