sarnex has quit [Remote host closed the connection]
sarnex has joined #dri-devel
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
ybogdano has quit []
<airlied>
dj-death: updated the MR
<airlied>
dj-death: might just enable it by default, since it passes all the CTS tests now
ybogdano has joined #dri-devel
ybogdano has quit []
ybogdano has joined #dri-devel
Kayden has joined #dri-devel
<airlied>
Lynne: doesn't radv report R10X6 now?
ybogdano has quit []
ybogdano has joined #dri-devel
<Lynne>
it does, actually, nevermind
<robclark>
jekstrand, danvet: adreno doesn't allocate mid batch (fwiw) and there is an igt test that should ensure that all the possible reclaim fail scenarios for submit ioctl are tested (well, at least all the non drm_sycobj ones, that still needs to be added to itg test... *but* demand-paging is a thing we might want to do some day and for any driver that means mid-batch allocations.. which might be fun
<robclark>
I guess it helps that the output of the binning pass isn't varyings but viz stream, and we can pre-calculate the worst case size (and if needed deal with case where viz stream bo is too small in cmdstream+hw)
<Lynne>
airlied: btw multi-slice h264 files still have minor corruption on radv
<Lynne>
I'll test on anv in a bit
<Lynne>
(use that m2ts sample I sent you)
srslypascal has joined #dri-devel
<airlied>
Lynne: I wonder if it's something else than the fact that are multistream
<alyssa>
jekstrand: danvet: Mali absolutely has to allocate mid batch for the tiler hea
<alyssa>
heap
<alyssa>
(Valhall allocates varyings dynamically out of the tiler heap, fwiw)
<airlied>
Lynne: oops I did noticed that and messed up my last test of it
<alyssa>
this works by reserving a large heap but not committing memory
<airlied>
Lynne: so I'm getting a profileIdc of 122 which isn't in the vulkan enum
<alyssa>
the kernel pagefault handler will then commit 2MB chunks at a time as needed by the hw
<alyssa>
"growable" memory
<Lynne>
airlied: 122 is profile_high_422
<airlied>
ah, probably need to get that defined by the std header
<Lynne>
also, the radv 422 patch is fine, but you should probably only advertise 422 if the input is 422, and only 422, unless the driver and/or hardware can convert 422 to 420 and vice-versa
<airlied>
Lynne: what format= in the command line do I need to test 422 content?
<Lynne>
just disregard the header profile values, profileIdc is a bitstream value, the spec shouldn't define these, hevc come up with a new profile every few months, no way they can keep up
<Lynne>
err, nv16 for 8-bit
ngcortes has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
mwalle has quit [Quit: WeeChat 3.0]
* airlied
can't spot why 422 isn't working on radv for me, will go fix anv scaling first :-P
<Lynne>
I think because it may want single-plane 422...
<Lynne>
maybe, for some reason vadumpcaps doesn't list "pixel_formats" for 422
<Lynne>
it does list a 422 surface format, as YUY2, which is ffmpegese for YUYV422 (format=yuyv422), which is vulkanese for VK_FORMAT_G8B8G8R8_422_UNORM
jewins1 has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: okay fixed anv I think
sgruszka has joined #dri-devel
<Lynne>
btw is srcBufferOffset wired up on the decode-side?
<airlied>
should be
<airlied>
Lynne: the amd hw should accept a 2-plane 422, at least the hw surface programming shouldn't be same as 2-plane 420 I think
fxkamd has quit []
<airlied>
but maybe it just doesn't support it
<Lynne>
why does vaapi signal it? I did think it was strange, but 422 is widely used in broadcasting
<Lynne>
anv is still not fixed, I think
<airlied>
vaapi driver seems to have it hardcoded
ice99 has joined #dri-devel
<airlied>
Lynne: wierd, I'm seeing the right colors at least now
Duke`` has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
<Lynne>
I can't pull from your repo?
<Lynne>
I get 7e80807a070c as the last commit, not 7dcf00ba
<Lynne>
did you change the branch or something?
<airlied>
anv-vulkan-video-decode, I also pushed the prelim one
<airlied>
anv-vulkan-video-prelim-decode just pushed that as well
fab has joined #dri-devel
<Lynne>
yup, works now
tzimmermann has joined #dri-devel
kts has joined #dri-devel
<Lynne>
radv didn't like host mapped at all
<Lynne>
though I remember it used to work...
<Lynne>
pushed to my repo, going to test on anv
agd5f_ has joined #dri-devel
<Lynne>
broken there too, I'm not sure srcBufferOffset is respected
<airlied>
Lynne: aligned correctly?
<airlied>
both drivers add it in at the right place
<Lynne>
yeah, I call GetMemoryHostPointerPropertiesEXT to check, and buffer creation doesn't fail either
sarnex_ has joined #dri-devel
<Lynne>
(anv is nasty, GetMemoryHostPointerPropertiesEXT passes but buffer creation doesn't if the ptr is unaligned!)
<airlied>
but you respect VkVideoCapabilitiesKHR::minBitstreamBufferOffsetAlignment
<airlied>
?
<airlied>
ah the host ptr one might be closer
agd5f has quit [Ping timeout: 480 seconds]
sarnex has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: I'm seeing values not aligned to that
bgs has joined #dri-devel
<airlied>
though I'm not sure at least the radv value for it is correct, the anv one could be reduced with some work
srslypascal has quit [Ping timeout: 480 seconds]
<Lynne>
fixed
<Lynne>
still doesn't work on anv
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
shoragan has joined #dri-devel
<airlied>
Lynne: still doesn't seem to take minBitstreamBufferOffsetAlignment into account (not minBitreamBufferSizeAlignment)
<Lynne>
oh, forgot about that one
<Lynne>
still, minImportedHostPointerAlignment is 4096, it's probably way above any other alignment
<airlied>
yeah but the offset isn't aligned correctly then
<airlied>
you get the ptr aligned to 4096, but you can end up with an offset of 16
* airlied
has no idea what the actual reqs on amd hw are here
<airlied>
the register is written a 64-bit addr, but no info on alignment for it
YuGiOhJCJ has joined #dri-devel
rmckeever has quit [Quit: Leaving]
<airlied>
not sure how tricky it would be to make that all work, at least on anv it'll need some hacks to get it down to byte
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<Lynne>
as long as the first slice doesn't have to be at offset 0, I can align to both
frieder has joined #dri-devel
<Lynne>
for some reason, I can't do that?
<Lynne>
doesn't work on radv
<Lynne>
I'm just setting the first slice at an offset
<Lynne>
it works if the offset for the first slice is below or equal to 32
danvet has joined #dri-devel
fab has quit [Quit: fab]
srslypascal has joined #dri-devel
mwalle has joined #dri-devel
<airlied>
Lynne: I suspect 32 is the radv min alignment there
<Lynne>
not max? I haven't found a value which works above 32
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<airlied>
Lynne: I see frame corruption on some frames that are getting 16 aligned vals for buffer offset
<airlied>
you kinda need an aligned malloc
ice99 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
<airlied>
Lynne: not really seeing how to make that work, realloc and alignment are kinda not friends
tursulin has joined #dri-devel
srslypascal is now known as Guest2264
srslypascal has joined #dri-devel
jkrzyszt has joined #dri-devel
<Lynne>
we align our allocs to the CPU simd size, which is 32 bytes in our case
<Lynne>
but regardless, disable host mapping and increment slices_size after allocating it and you'll see corruption
Guest2264 has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
pochu has joined #dri-devel
<Lynne>
pushed to my repo
<Lynne>
just change vkpic->slices_size += 0; to 64 to see corruption
<Lynne>
for normal frames, we host-map the pointers to vkbuffers, which lack an offset alignment requirement, so we're free to
<Lynne>
but for bitstream buffers, I need to be able to offset the first slice
<Lynne>
to satisfy the secondary offset requirement
rasterman has joined #dri-devel
fab has joined #dri-devel
elongbug has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
frankbinns2 has quit []
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
<airlied>
well vk buffers have an offset alignment requirement if you suballocate them from a memory allocation
xroumegue has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
lynxeye has joined #dri-devel
<Lynne>
it's memory importing in this case
<Lynne>
the black magic method we're using by specifying memory which may be or may not even be part of our address space and offsetting it has worked 100% of the time so far
<jani>
tzimmermann: are you going to send another (final?) drm-misc-next pull request this week?
<jani>
tzimmermann: I'd really like to get b494d6283deb ("drm/edid: remove redundant _drm_connector_update_edid_property()") into drm-next, so I could backmerge, apply a few dependent patches on drm-intel-next, and send the final drm-intel-next pull request for this cycle
mvlad has joined #dri-devel
ice9 has joined #dri-devel
ahajda has joined #dri-devel
ice9 has quit [Quit: Leaving]
ice9 has joined #dri-devel
<danvet>
vliaskov, strictly speaking all you have to do is wire the property up, but do nothing
<danvet>
because the damage rect stuff is strictly an optimisation, userspace still must render the full fb
<danvet>
so vkms can continue to "scan out" the entire thing
<danvet>
vliaskov, so the fb_blit you're doing just copies part of the fb over itself, so that's not optimizing anything and looks a bit strange (or I'm misreading)
<danvet>
if you want to optimize, you would need to change the blend() function
<danvet>
but that's a pretty substantial redesign, because we'd need to fix it to be more incremental
<danvet>
what could work is 1. refactor blend to only render a sub-rectangle of the crtc
<danvet>
2. compute the overall crtc damage (currently no helper for those I think, but manual upload drivers need that so maybe good to share across drivers)
<danvet>
3. then switch blend() to only recompute the damaged (in crtc coordinates) area
<danvet>
we must still compute the crc32 over the entire area
<danvet>
oh I just noticed: another optimization would be to make the crc computation optional
djbw has quit [Read error: Connection reset by peer]
<danvet>
and only do it when we need it
<danvet>
that should help with using vkms for compositor testing ...
<danvet>
vliaskov, I thought there was some discussion about crtc damage rects in the past, but I can't find it anymore
devilhorns has joined #dri-devel
<danvet>
oh also we could eventually extend this to handle multiple crtc damage rects
<danvet>
e.g. if you have a moving cursor in one are and a blinking cursor of an input field somewhere else
<danvet>
i915 psr code does have some of the crtc damage calcs already iirc
<javierm>
danvet: I don't think that copies part of the fb over itself but parts of the shadow buffer ?
<danvet>
javierm, yeah, but neither did the previous code
<javierm>
danvet: so I think that changing to iterate over damage clips rather than copy the full rect is still an optimization
<danvet>
so we really don't need a copy there, not even a partial one
<danvet>
the vkms "copy" for "scan out" happens in blend()
<javierm>
danvet: ah, I see
<vliaskov>
thanks danvet. So is anything accomplished with just enabling the property for vkms?
<danvet>
this just copies the structs around so we have all the required information
<danvet>
vliaskov, you can run tests
<danvet>
like compositors
<danvet>
so I think yes
<danvet>
also we could use vkms to test the damage clip helpers a bit (althought those should have full coverage with unit tests)
<danvet>
especially with crtc coordinate damage the helpers become crucial
<danvet>
since anything that impacts the resulting blended colors must be a full damage clip for that fb
<danvet>
e.g. lut/color stuff, blending modes, position changes, ...
<danvet>
vliaskov, what I'm saying is that the minimal damage implementation is actually less than what you do
<danvet>
any driver could set this actually
<danvet>
but the full vkms damage clip support is quite a bit more (i.e. the steps I laid out)
<danvet>
it should also help with performance in compositor testing when you have blinking cursors and stuff and don't capture crc (if we make the crc stuff optional too)
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<vliaskov>
Yes, I did see that the vkms atomic_plane_update updates frame metadata, and actually performs no copy. So it is odd to try to do a partial update (i saw similar code in mga, simpledrm or i915 iirc).
<vliaskov>
I also see vkms_compose_planes currently keeps allocating output and intermediate line buffers... with an actually optimization, I assume we would keep re-using buffers in a refactored/partial blend() ?
<danvet>
vliaskov, yeah we'd need to reuse the old one
<danvet>
at least if the resutling crtc damage rects is less than the overall crtc
<danvet>
otherwise we can just allocate everything anew
<vliaskov>
understood. I guess I am not clear what enabling the property as is actually means in terms of gains (if any gains for vkms). But that seems independent of the proposed optimizations. I 'll get more familiar with the generic drm/fb helpers.
jkrzyszt has joined #dri-devel
<danvet>
vliaskov, for vkms itself not really anything
<danvet>
but vkms is for testing, so enabling it allows you to test that compositor code a bit
<danvet>
with pure sw
<danvet>
so there's a benefit in enabling that one-liner (maybe even behind a config option again, so that compositors can be tests both with and without damage support supported in the driver)
<danvet>
so maybe a bit more than a one-liner :-)
<vliaskov>
i see, thanks
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
<vliaskov>
btw, I assume is the vkms TODO is up-to-date. There is an old item "Add background color KMS property[Good to get started]." but with no userspace using that prop, not sure if it still makes sense (patches were rejected twice in the past).
<vliaskov>
There was also an interesting vkms configfs attempt in July/August, but I am not sure when/if a v2 is coming out.
<tzimmermann>
jani, i would send that PR on early Thursda CET. would this work?
jdavies_ has quit [Remote host closed the connection]
ice9 has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
minecrell has quit [Read error: Connection timed out]
minecrell has joined #dri-devel
devilhorns has quit []
jim has joined #dri-devel
ice9 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
jim has quit []
kts has quit [Quit: Leaving]
phasta has joined #dri-devel
<jani>
tzimmermann: yeah, if airlied also merges it in a timely fashion *wink wink*
<tzimmermann>
jani, if it's just one patch, maybe cherry-pick?
frankbinns1 has quit []
frankbinns has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<jani>
tzimmermann: no, it's a bunch, I just pointed at the most recent one
<tzimmermann>
danvet, ^ can we have two drm-misc-next PRs this week?
<tzimmermann>
i'd prepare one today and another one on thursday
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<jani>
oh, that would work nicely too
<danvet>
tzimmermann, yeah can do and also fast-track if needed
<danvet>
just ping me or something like that
<tzimmermann>
danvet, thank you
jdavies has joined #dri-devel
jdavies is now known as Guest2282
<jani>
+1
jdavies_ has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
libv_ is now known as libv
pendingchaos_ has joined #dri-devel
Guest2282 has quit [Ping timeout: 480 seconds]
<tzimmermann>
danvet, last week's PR for drm-misc-next has not been merged yet
pendingchaos has quit [Ping timeout: 480 seconds]
<tzimmermann>
can you take care of it?
<danvet>
in some meetings, but will do in a bit
<tzimmermann>
thank you
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
X512 has joined #dri-devel
<X512>
Is it possible to upstream alternative non-DRM interface for Vulkan drivers (RADV, ANV)?
pendingchaos_ is now known as pendingchaos
<karolherbst>
no
<karolherbst>
two reasons: 1. we probably won't maintain them 2. whoever wants them to be added has to give a _hard_ promise to maintain them for at least 10 years
<karolherbst>
also.. having alternative interfaces for the same thing is also very frowned upon anyway
<karolherbst>
however, if you can show in a downstream project that moving to a different kind of API is totally worth it, be our guest, but don't complain if the work is wasted
<karolherbst>
X512: anyway... _why_ would you see alternative interface added in the first place?
<X512>
Because Haiku GPU drivers are userland based and FD can't be used for accessing device. Some data structure on client side is needed.
elongbug has quit [Remote host closed the connection]
<karolherbst>
ohh you meant in the userspace driver
elongbug has joined #dri-devel
<karolherbst>
ehh I think we already support haiku for some stuff in mesa, no?
<X512>
There are GPU server that directly control hardware from userspace and client processes access server via IPC.
<karolherbst>
right...
<X512>
Only software rendering is currently upstreamed for Haiku.
<karolherbst>
I mean.. I'm convinced that the 100% userland approach is neither sustainable nor secure, but I think as long as it's not a pita to maintain it (and the CI is in place) it shouldn't be an issue
<karolherbst>
it's just easier to just support whatever linux provides for everybody
<X512>
I don't understand how userland approach can be less secure than kernel.
<X512>
Every small memory buffer overrun etc in kernel module can be used to hijack kernel and gain root access.
<karolherbst>
sure, but the userland approach means, that GPU server has access to all kernel memory
<karolherbst>
so you can own the system this way
<karolherbst>
well.. maybe haiku has a better approach on how to configure DMA
<karolherbst>
dunno, but doing this in userspace makes the entire isolation thing pointless
tarceri_ has joined #dri-devel
<X512>
Kernel GPU module also has access to whole physical memory. Userland GPU server has much less probability to expluatate vurnerabilities.
<karolherbst>
the point is: userspace doesn't
<karolherbst>
with userspace GPU drivers, userspace has that access
<karolherbst>
and not even as an exploit, just by definition
<X512>
And? The question is probabiliy of hacking, not possibility.
<karolherbst>
which is the same
<X512>
GPU server is priveleged process with root access. No authorized code can be loaded to it. So I see no problem.
<karolherbst>
one bug in the kernel == owned, one bug in the userspace GPU driver == owned
<karolherbst>
it's not about loading anything into it
<karolherbst>
GPU drivers are complex
<karolherbst>
you have to constantly configure DMA stuff
<karolherbst>
there can be a bug making the driver access all kernel memory and do random things
<X512>
Kenel code have much larger attack surface. In addition to GPU DMA any kernel structures can be also attacked.
<karolherbst>
anyway... having userspace access to all kernel memory by design sounds like a bad thing, tbh
tarceri has quit [Ping timeout: 480 seconds]
<karolherbst>
in linux that would immediatly by a CVE
<X512>
One of big problem with Linux DRM kernel drivers is that it are not designed to be portable and it are hard coded to unstable internal Linux API.
<karolherbst>
sure
<karolherbst>
that's how linux drivers are developed
<X512>
Bringing large Linux compat layer to Haiku kernel is a bad idea I think.
<karolherbst>
but quite frankly: why should we adjust for 0.1% of users if that means taking 10+ other kernels into account?
<karolherbst>
that's a lot of work with no benefit
<karolherbst>
right...
<X512>
Vendor lock-in is a bad idea in general for healthy open source community.
<karolherbst>
but if one or two starts to reimplement GPU drivers for all the hw we support it's a doomed project from the start anyway
<karolherbst>
heck... even maintaining a compat layer is too much work for BSD folks generally
<X512>
For example NVidia have OS abstarction layer in kernel drivers so it can be easily ported.
<karolherbst>
and maintaining those layers is probably 5% the work you need for a full driver
<karolherbst>
right
<karolherbst>
but the thing is: they get money out of it
<karolherbst>
and have enoguh to actually let people work on this
<turol>
gitlab is refusing to let me log in on a browser profile which had previously accessed the old bugzilla
<X512>
I made functional driver for Radeon SI GPUs that works with Mesa RADV driver. So it is not impossible task.
<turol>
what do i need to clear to make it work?
<karolherbst>
X512: I'm not saying it's impossible, I'm just saying it's a lot of work doing it properly
<karolherbst>
how much of the available hardware do you support?
<karolherbst>
do you also support the GL driver?
<karolherbst>
how many bugs does it have?
<karolherbst>
does it support all the display stuff correctly?
<daniels>
turol: probably need to unblock reCAPTCHA
<karolherbst>
did you already implement DP-MST?
<X512>
Linux is not an option for me so I am ready to spend resources to bringing GPU acceleration stack for Haiku.
<karolherbst>
yeah, fair
<karolherbst>
but don't say we didn't warn you
<karolherbst>
I mean.. it is a cool project and everything, but it's also a lot of work
<X512>
Supporting all hardware is not needed and it is very hard task. Support can be limited by some subset of popular GPUs.
<X512>
On Haiku following interface is currently used instead of DRM device FD:
<turol>
daniels: i've already allowed javascript on freedesktop.org and there's no other sites loaded into the login form
<karolherbst>
X512: yeah.. no
<karolherbst>
we won't support something if the goal isn't to do it properly
<karolherbst>
yes, supporting all the hardware is needed
<X512>
- int err = drmSyncobjCreate(device->drm_fd, flags, &sobj->syncobj);
<X512>
+ int err = device->acc_drm->vt->DrmSyncobjCreate(device->acc_drm, flags, &sobj->syncobj);
<X512>
Accelerant object holds GPU server IPC connection context and some private state.
<karolherbst>
sure
<karolherbst>
but why should _we_ support/maintain it?
elongbug has quit [Remote host closed the connection]
<karolherbst>
unless there is an active and big community around whatever is done for haiku, it all means, that sooner or later we will be the ones having to support/maintain it
<daniels>
(and, realistically, it gets broken all the time)
elongbug has joined #dri-devel
<karolherbst>
in avarage every 1 or 2 months a new person comes in and asks for that kind of stuff, if we had said yes to everybody, we'd have ~25 of those interfaces to maintain
<karolherbst>
because big surprise, those people move on and give up a few months later
fxkamd has joined #dri-devel
<daniels>
it's not 'just' a five-entry vtable either; it means that every single platform is held to that interface as the lowest common denominator of what they can support, so if you suddenly go on holiday or lose interest, then no-one else can move forward until you've found some time to catch up
phasta has quit [Quit: Leaving]
<X512>
25 interfaces is good idea. Just make proper winsys abstraction like it is done in RADV or libdrm_amdgpu.
<X512>
And yet another OS driver interface will be an implamentation of winsys function table.
<daniels>
have you looked at how rapidly libdrm-amdgpu changes?
<X512>
Not so rapid really.
<karolherbst>
uhhh
<karolherbst>
you underestimate how much work that stuff is
<karolherbst>
I can guarentee you, that the driver you wrote is less than 1% of what you actually need for a working driver
<karolherbst>
at least for AMD hardware
<karolherbst>
if the goal isn't to support all the hw from at least 10 years ago, it's a doomed project
<X512>
I already adapted libdrm_amdgpu to Haiku new accelerant interface. It do not need libdrm.so at all now. Thanks to amdgpu_device_handle opaque pointer instead of direct FD use.
jewins has joined #dri-devel
<X512>
Why? It can be a user base with small set of working GPUs.
<X512>
Why libdrm do not use opaque device pointer...
<karolherbst>
X512: because if you only support 1 or 2 GPUs it's irrelevant for us
<karolherbst>
then you can maintain it downstream
<karolherbst>
if you only support your hardware, there is no reason for us to accept your code
<jenatali>
I remember jekstrand talking about considering WDDM support for at least one of the drivers he was working on. Would be interesting to see if there's an abstraction that could support that, DRM, and Haiku
<X512>
That will be nice.
<karolherbst>
jenatali: right.. but WDDM is something we'd know wouldn't just vanish
<X512>
In theory Mesa Vulkan drivers can be used with Windows kernel GPU drivers.
<X512>
Haiku have quite long history. It will not vanish in near future.
<karolherbst>
1. build a strong and sustainable community first before even considering upstreaming, once it took of and people actually use it and random contributors make sure it works on all kind of hardware, then you can come back and ask us
<karolherbst>
or
<karolherbst>
2. we accept it, and pull it out in half a year, because you lost interest/moved on and we get the hate, because we are the badies here
<karolherbst>
we kind of prefer 1.
<X512>
Haiku origin BeOS is older than Linux.
<karolherbst>
that's not the point
<karolherbst>
what makes _your_ work not vanishing
<karolherbst>
what if there are two other haiku devs having the same idea but different APIs
<karolherbst>
how should we know what's the "correct/main" one
<X512>
Removing hardcoding from DRM FD would be beneficial in general, not only for Haiku. Mentioned WDDM is a good example.
<karolherbst>
or maybe there will be 5 different APIs for different hardware, because it's just random people doing stuff
<karolherbst>
again
<karolherbst>
this isn't about code
ManMower has joined #dri-devel
<karolherbst>
I honestly don't care what potential or "maybe" benefits it has to the code
<karolherbst>
what matter is the sustainability of this project or if we just end up removing it at the end of this year
<karolherbst>
or rather _why_ does this has to go upstream and can't be maintained downstream for now
<X512>
I do not plan to give up this work for this year :)
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<karolherbst>
yeah.. everybody said that before giving up a few months later
elongbug has quit [Remote host closed the connection]
<karolherbst>
also
<karolherbst>
it doesn't even matter if you keep working on it, what matters is, if you are able to build a community around it
<karolherbst>
or if this will be the official haiku way of doing GPU drivers
<karolherbst>
or could there be like 5 alternative projects doing all the same but with different APIs
<karolherbst>
stuff like that
<karolherbst>
what if next week another person chimes in and said "hey, can I upstream my non DRM API for radeon GPUs on haiku?"
<X512>
The problem is not potential multiple non-DRM APIs. The problem is a lack of device opaque pointer support.
<X512>
It will be easier to manage out of tree code if it will not patch a lot of places.
<karolherbst>
I mean.. sure I get why you want to upstream it
<karolherbst>
and ultimately it will be up to the radv/readeonsi devs to either accept it or not
<karolherbst>
and yeah, maybe you are the one of the few taking this very serious. If it already is shipped in official haiku images, that would be a good indicator of "yep, that project is legit"
<karolherbst>
or well.. included in official repositories or however that stuff works in haiku
<X512>
What about upstreaming software Haiku support (EGL support, Zink, lavapipe)?
<danvet>
maybe I missed something, but my take is ... why can't that gpu process emulate the linux ioctl interface over an fd?
<X512>
It is planned to switch to glvnd and abandon Mesa Haiku libGL implementation and use EGL glvnd driver instead.
<danvet>
linux has cuse (chardev in userspace) for this
<karolherbst>
X512: we already have that kind of stuff, yeah. but it also doens't seem to be a burden so far
<karolherbst>
but it's software rendering
<karolherbst>
that's the easy part
<X512>
Haiku doesn't. Haiku also have its own IPC kernel objects (port_id) that are not FD based.
<danvet>
tursulin, since the duplicated function is still there in the drm-tip merge I guess some backmerge would be good to nuke it for real
<danvet>
it's very confusing ...
kts has joined #dri-devel
<tursulin>
danvet, sorry does not ring a bell - what duplicated function?
kts has quit [Remote host closed the connection]
kzd has joined #dri-devel
<tursulin>
danvet, okay rodrigovivi got me up to speed on that one
fab has quit [Quit: fab]
gawin has joined #dri-devel
<jekstrand>
We decided to have a WDDM2 fight without me? *sad face*
<zmike>
"decided" is a strong word to use there
<karolherbst>
jekstrand: you wanna fight?
<karolherbst>
but yes, from the last time we decided to exclude jekstrand from any fights, because of how OP he is
Terman has quit [Remote host closed the connection]
fxkamd has quit []
<gawin>
do wide points and lines have formal definition? I'm reading specs and cannot spot anything so far. (or can I know from state when it's used?)
<jekstrand>
Nah, I don't wanna fight.
<jekstrand>
I'm just amused.
<karolherbst>
:P
<ajax>
gawin: glspec2.1.pdf section 3.4.2 "Other Line Segment Features"
<ajax>
for wide lines anyway
<gawin>
thanks
Jeremy_Rand_Talos_ has joined #dri-devel
<X512>
Is it possible to contact amdgpu/RADV developers? #radeon-dev channel seems have too low activity.
<ajax>
often easier to find the defintion for old gl features in old gl specs
<emersion>
X512: #radeon is the channel
<karolherbst>
open a MR 🙃
<X512>
Mistake, yes #radeon. Activity is low.
<X512>
I want to ask some questions about Radeon GPU operation. It is hard to understant some things from amdgpu kernel code and it seems no public documentation.
<MrCooper>
no better place for those questions than #radeon
Jeremy_Rand_Talos has quit [Ping timeout: 480 seconds]
<ajax>
many of them are for older gpus but much of it still applies
jewins1 has joined #dri-devel
<jenatali>
jekstrand: I also wouldn't call that a WDDM2 fight. But I tried to summon you, you just didn't show up :P
<zmike>
you'd know if he did by the sound of an approaching keyboard
jewins has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: hehe
<jekstrand>
zmike: Not nice, but totally fair. :P
<X512>
Somebody is planning to make WDDM2 winsys support?
<jekstrand>
We've had some Windows present for a while and we just landed more.
Cyrinux has quit []
<jekstrand>
Or are you talking about the radv winsys abstraction?
Cyrinux has joined #dri-devel
<X512>
Yes. Make RADV working with Windows kernel drivers.
<jekstrand>
I did start typing on that ~1yr ago.
<jekstrand>
I stopped short of actually submitting GPU work.
<danvet>
tursulin, yeah sorry I split the reply across irc and m-l :-)
<MrCooper>
X512: Windows kernel drivers have no stable UAPI AFAIK
<jenatali>
That's right
fab has joined #dri-devel
<jenatali>
But also there's only ~7 entrypoints where there's driver-private data that can be affected. The rest is stable
<tursulin>
danvet, its okay, backmerge done and fixup removed
<danvet>
tursulin, thx!
<X512>
Haiku also have no stable UAPI and syscalls. Applications must use API provided by shared libraries.
<X512>
GPU server is also planned to have no stable IPC protocol. Server side driver and client interface library always come in pair.
<karolherbst>
well.. nobody will use the low level APIs directly anyway
<MrCooper>
X512: it means a RADV Windows winsys could break with any new AMD Windows driver release
<airlied>
danvet: doh, had all the next merges locally, just didn't push it out for some reason
<danvet>
well now it wont work so well :-)
<danvet>
airlied, I'm building the drm-misc-next one rn, so if you only have two I guess toss it?
<danvet>
I pushed the -gt-next one already
<danvet>
ok -misc-next too because the script just finished :-)
<danvet>
tzimmermann, ^^
<jekstrand>
MrCooper: Yes, there are ways around that but they require AMD's involvement.
<airlied>
danvet: cool, I'll rework whatever was left, i think it was just one amd one
<X512>
It is good that RADV have winsys concept. ANV driver just use ioctl directly.
<X512>
RADV have 2 levels of abstraction: RADV/Gallium winsys and libdrm_amdgpu.so. Honestly I don't understand why second level of abstraction is needed. ANV have zero layers.
<X512>
For Haiku needs a bit adapted libdrm_amdgpu.so is enough.
<danvet>
airlied, oh right agd5f does lowercase pull so I always miss them on first pass :-)
<MrCooper>
jekstrand: seeing as AMD's Linux teams so far are barely acknowledging RADV's existence, I wouldn't bet on the Windows teams caring :)
<agd5f>
danvet, would you prefer upper case?
<danvet>
agd5f, I think you're not the only one, so meh
<danvet>
it's more that I never know how case-insensitive search here in mutt works :-)
<MrCooper>
X512: libdrm_amdgpu is used by AMD's Linux UMDs as well
<jekstrand>
MrCooper: Well, yeah...
<jekstrand>
X512: RADV's winsys concept is very not great. I'm pretty sure bnieuwenhuizen wants to get rid of it. It also wasn't as helpful as you'd expect for my WDDM2 port.
<jekstrand>
Not that some abstraction isn't helpful. It was just the wrong abstraction.
<airlied>
the radv winsys abstraction was useful to plug in the null winsys later, but it might still have been a bad idea, and libdrm_amdgpu deps are still a bit of a mess
<X512>
Two new functions are added to libdrm_amdgpu.so for Haiku support: amdgpu_device_initialize_haiku, amdgpu_device_get_accelerant.
genpaku has quit [Remote host closed the connection]
jdavies_ has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
genpaku has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: office...again]
agd5f_ has quit [Ping timeout: 480 seconds]
X512 has quit [Quit: Vision[]: i've been blurred!]
agd5f has joined #dri-devel
<karolherbst>
dcbaker: if I bump the meson requirement for rusticl, is there anything specific I need to do? Like adding a notice to release notes or something?
<dcbaker>
karolherbst: I don't think so... I don't think any distros are building rusticl that aren't also using bleeding edge meson
<karolherbst>
okay, fair enough
deathmist2 has quit [Remote host closed the connection]
deathmist2 has joined #dri-devel
jdavies has joined #dri-devel
bgs has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
jdavies is now known as Guest2313
heat has quit [Remote host closed the connection]
<tzimmermann>
jani, danvet, i've sent out the drm-misc-next PR
<danvet>
airlied, ^^
<airlied>
okay I'll process that today, just have to reset my tree
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<DemiMarie>
karolherbst: what about the IOMMU? Without an IOMMU your system is not secure, period.
<DemiMarie>
Unless you trust every DMA-capable device and the drivers for all of them.
<DemiMarie>
X512: another option might be to use a global hash table with FDs as keys.
srslypascal has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
jkrzyszt has quit [Remote host closed the connection]
<airlied>
Lynne: so you call av_fast_realloc which degrades eventually into realloc which does no alignment on Linux at least
nchery has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
Cyrinux has joined #dri-devel
oneforall2 has joined #dri-devel
ahajda has joined #dri-devel
jkrzyszt has joined #dri-devel
nchery has joined #dri-devel
gouchi has quit [Remote host closed the connection]
ice9 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Guest2313 has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
mvlad has quit [Remote host closed the connection]
<jenatali>
Heh, I should've skipped VK1.1 and gone straight for 1.2, looks like we basically already support it...
<HdkR>
Number goes up! \o/
<jenatali>
But 1.3 requires BDA and that's... going to take a while
unerlige has joined #dri-devel
bluebugs has joined #dri-devel
Leopold_ has joined #dri-devel
<Lynne>
airlied: that's irrelevant, I just need to add a pre-padding to the first slice, then via both that and the bitstream offset, I can align to whatever
<Lynne>
as long as the bitstream offset align is less than or equal to the maximum padding I can have before the first slice
<Lynne>
rewriting all slice offsets is still cheaper than memcpy
<airlied>
Lynne: so the buffer offsets I was getting last I tested still has % 32 left overs when I printed them out
jkrzyszt has quit [Remote host closed the connection]
fab has quit [Quit: fab]
<Lynne>
hmm, codec-dependent?
vliaskov has quit [Remote host closed the connection]