ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
<ity>
Hmm, I am trying to get familiar with the overall thing so that I can identify what I want to delve deeper into.
<ity>
Hmm, EGL & GLX share the actual OpenGL implementation I presume, right?
<jenatali>
For GL, the code in src/mesa calls through the gallium (pipe) interface to the code in src/gallium/drivers/<driver>. Also the code in GLX/EGL calls through (on Linux) the src/gallium/frontend/dri code which then also calls that same pipe interface
<mareko>
stepping through the code using a debugger is probably the fastest way to figure out how it works
<jenatali>
The various gallium drivers get support code like compiler bits or image tiling libraries from the corresponding vendor-specific dirs
<jenatali>
mareko: that extra indirection from the dri frontend confounded me for a while
<jenatali>
Since wgl doesn't have it
<ity>
Pipe interface?
<ity>
I will certainly try stepping with a debugger
<airlied>
ity: you can't get familiar with the overall thing, it's too big
<airlied>
just get a vague outline, work out what might be interesting or needs a fix, and focus on that
<jenatali>
ity: it's the interface between frontend and driver. All the types are prefixed with pipe_
zxrom has quit []
bolson has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<alyssa>
airlied: is right
<alyssa>
I openly don't grok e.g. the GL frontend
<alyssa>
or the GLSL compiler
<alyssa>
hasn't been particularly career limiting :D
<alyssa>
(the galliumy and nir-y bits I get. the _mesa-y and yacc-y bits I don't)
flynnjiang has joined #dri-devel
<ity>
Ooooh, yea I want a vague outline, then find something interesting and delve into that
<ity>
jenatali: Oh, I see! Interesting, I'll try grepping for pipe_
Guest2398 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
yyds has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
macromorgan has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
ced117 has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
aravind has joined #dri-devel
bmodem has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
surajkandpal has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
Leopold has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
kts has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
sima has joined #dri-devel
sgruszka has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
ghishadow has joined #dri-devel
passimoto has joined #dri-devel
kts has joined #dri-devel
<passimoto>
There's also suchthat functionality by two lists as well as list1 in openmath , so it has everything but is rather large codebase.
fab has joined #dri-devel
jkrzyszt has joined #dri-devel
warpme has joined #dri-devel
<passimoto>
set1 but anyways it looks like we can expose this mode this year with using openmath and w3 consortium and some libs.
<passimoto>
There's no point to fight over it, it's not very complex, those people on the island were just crazy hope to never deal with them again, don't send such around me, very obnoxious, enjoy your work instead, it's rewarded with salaries after all.
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
jfalempe has joined #dri-devel
ghishadow has quit []
kts has quit [Ping timeout: 480 seconds]
<passimoto>
I have been somewhat doing the needed work but with half barrels from my free time, I think there's no big problem and I have the needed experience around systems, those kits look good to me they offer everything imaginable.
sgruszka has quit [Ping timeout: 480 seconds]
<passimoto>
If everything works out this year, like expected the big thanks goes to hosts of the tournaments who arranged work to me so I could buy something at times, this has opened up all the research in free days. https://store.pfu-us.ricoh.com/cg01000-298001/ that gadget looks good there are other pictures it has tablet mode at 270 degree rotation too, this seems universal and good to mount foldable keyboard with magnet.
frieder has joined #dri-devel
tursulin has joined #dri-devel
dorcaslitunya has joined #dri-devel
kts has joined #dri-devel
jsa has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
frankbinns1 has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
apinheiro has joined #dri-devel
passimoto has quit []
lynxeye has joined #dri-devel
trenchsitting has joined #dri-devel
<trenchsitting>
You would not get any salary from such opportunity, since you need to have proper results in that series of tournaments to claim salary, your only results are at terroring customers in tropical regions. They do not pay for such "heroics".
mripard has joined #dri-devel
JohnnyonFlame has joined #dri-devel
hansg has joined #dri-devel
<airlied>
Lynne: i did make a little progress on av1. hopefully figure out tomorrow
hansg has quit [Read error: Connection reset by peer]
hansg has joined #dri-devel
sgruszka has joined #dri-devel
frankbinns1 is now known as frankbinns
chaos_princess has quit [Quit: chaos_princess]
cmichael has joined #dri-devel
chaos_princess has joined #dri-devel
davispuh has joined #dri-devel
mvlad has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
flynnjiang has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
frieder has joined #dri-devel
dwfreed has joined #dri-devel
dorcaslitunya has quit [Ping timeout: 480 seconds]
<karolherbst>
mareko: should I just push to your MR (the pipe_box one) and merge it or do you want to include the patch I posted?
ghishadow has joined #dri-devel
kts_ has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
dorcaslitunya has joined #dri-devel
zhiwang has quit [Remote host closed the connection]
hansg has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
danylo has quit [Quit: Ping timeout (120 seconds)]
danylo has joined #dri-devel
sgruszka has quit [Read error: Connection reset by peer]
trenchsitting has quit [Remote host closed the connection]
sgruszka has joined #dri-devel
mwk_ has joined #dri-devel
mceier has quit [Remote host closed the connection]
mceier has joined #dri-devel
mwk has quit [Read error: Connection reset by peer]
<transmittingsense>
there was a pdf as to how i reached into numerateweb github , they carry mit license on the generated code, but openmath is sharealike common public license in other words public domain and so is rdf from w3, and i have another translator that would generate code without license incompatibility, i.e generator is mit but end program is not .
Leopold has quit [Remote host closed the connection]
yyds has joined #dri-devel
<jani>
hrmh, not pushing because 674dc7f61aef ("drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue") just regressed drm-misc-next for me: https://lore.kernel.org/r/87il1tt4f6.fsf@intel.com
yyds has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
vliaskov has joined #dri-devel
kts has joined #dri-devel
cmichael has quit [Quit: Leaving]
cmichael has joined #dri-devel
guludo has joined #dri-devel
rasterman has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
yyds has quit [Remote host closed the connection]
warpme has quit []
guludo has quit [Remote host closed the connection]
guludo has joined #dri-devel
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
warpme has joined #dri-devel
hansg has joined #dri-devel
<alyssa>
gm
kts has quit [Ping timeout: 480 seconds]
amarsh04 has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
alyssa has quit [Quit: alyssa]
prophetalike has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
kts has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
<prophetalike>
so all the opencl was already implemented in llvm clang boyi and multi2sim m2s-mgn and btw 2.1 compliance was included in both the frontend perser as well as in the hardware for gcn cards, so it's nothing that karolherbst had done, those solutions came out from my research labs, and i work alone. And every possible REAL solution you might have originates from my intermediate work. Just to say you are german scum karolherbst, and very
<prophetalike>
annoying puppet.
<prophetalike>
my all relatives send you straight to hell.
prophetalike was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
Amber_Harmonia_ has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
<Ristovski>
that guy needs a hobby other than trolling this channel lol
itoral has joined #dri-devel
<bcheng>
airlied, Lynne: is the av1 problem you're working on the references thing still?
jsa has joined #dri-devel
gloomineyes has joined #dri-devel
Calandracas_ has joined #dri-devel
<gloomineyes>
since my father borrowed around million dollars to the hotel where you came to terror me, when you contact him he lurks you into his place, removes your genitals and forces you to eat them. You viral scum puppet karolherbst , the island is entirely empty and out of tourism horizon ever since i left, so people know you are entire scammer terrorists.
<gloomineyes>
you are a fucking suicidal perv you motherfucker.
gloomineyes was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
grillo_06 has quit []
Calandracas has quit [Ping timeout: 480 seconds]
grillo_0 has joined #dri-devel
<grillo_0>
pq: about the possibility of combining the pixel conversion of the DRM core with that of VKMS. I think it could be viable, but the DRM goes from XRGB8888 -> format and in VKMS we have format -> ARGB8888 and ARGB8888 -> format. One option would be to just join these VKMS conversions to drm_format_helper, just adding another type of conversion.
<grillo_0>
Another option would be to change the DRM conversions from XRGB8888 -> format to ARGB8888 -> format, and after that add the VKMS conversions, to create a more cohesive API. But I don't know if this is desired, but I like the "not reinventing the wheel" thing
<pq>
wasn't it argb_u16?
<pq>
is that A vs. X such a big problem? I don't think I understand.
jsa has quit [Read error: Connection reset by peer]
ghishadow has quit []
<pq>
VKMS must be able to ignore the X of XRGB formats too, FWIW
agd5f has quit []
agd5f has joined #dri-devel
dorcasli_ has joined #dri-devel
dorcaslitunya has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
hansg has quit [Quit: Leaving]
aravind has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
sudeepd has joined #dri-devel
sudeepd_ has joined #dri-devel
<eric_engestrom>
gfxstrand: I don't understand `nvk_device_physical()`, given a `struct nvk_device *dev;` what's the difference between `dev->vk.physical` and `dev->pdev`?
<eric_engestrom>
`nvk_CreateDevice()` sets `dev->pdev` to the `VkPhysicalDevice` but I didn't dig further to figure out if these two are always a copy or if they can diverge, and if they can, when to use which
<eric_engestrom>
(in the context of your backport request of !27927)
lplc has quit [Quit: WeeChat 4.2.1]
lau has joined #dri-devel
lau has quit []
lplc has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
sgruszka has joined #dri-devel
jsa has joined #dri-devel
ezequielg__ has left #dri-devel [#dri-devel]
hansg has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
ninjaaaaa has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
ninjaaaaa has joined #dri-devel
ghishadow has joined #dri-devel
amarsh04 has quit []
cmichael has quit [Quit: Leaving]
<tzimmermann>
grillo_0, the current DRM conversion is tailored towards copying to the hardware framebuffer
<tzimmermann>
and there's no ARGB there
<tzimmermann>
so it's not really supported
<gfxstrand>
eric_engestrom: I'm trying to wean us off of dev->pdev. That's all.
<gfxstrand>
I should make a treewide change, probably
<gfxstrand>
Well, driver-wide
<gfxstrand>
They're the same pointer, just different types
<tzimmermann>
a few systems annouce argb surfaces that are really just xrgb; hence the xrgb_to_argb functions that set alpha to 0xff
<gfxstrand>
Yeah, xrgb is a mess. It's actually a different format in some hardware
<tzimmermann>
grillo_0, would it be possible to make vkms 'close enough' to drm helpers so that later patches could merge both?
<eric_engestrom>
gfxstrand: ack, so it looks weird because it's in a transition
<tzimmermann>
i.e., per-line conversion, clipping in the outer loop
<gfxstrand>
eric_engestrom: Yeah
itoral has quit [Remote host closed the connection]
<grillo_0>
pq: yeah, argb_16, sorry for the confusion
frieder has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
heat has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
agd5f_ has quit [Remote host closed the connection]
frankbinns has quit [Ping timeout: 480 seconds]
<eric_engestrom>
hehe, did you already have it in a local branch, or did my question trigger you into doing it? 😅
<gfxstrand>
Your question triggered it
<gfxstrand>
I've been meaning to do it for a while.
<eric_engestrom>
:]
lynxeye has quit [Quit: Leaving.]
agd5f has joined #dri-devel
jhli has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.2.1]
simondnnsn has quit [Ping timeout: 480 seconds]
ninjaaaaa has quit [Ping timeout: 480 seconds]
ninjaaaaa has joined #dri-devel
<lumag>
mripard, mlankhorst, dianders: There is a question on which abelvesa and me have been crashing our heads for quite a while. drm/msm/dp driver can support both eDP and DP targets. We are looking for a way to distinguish the sink type. Querying next_bridge->type will not work as it is the output of the bridge, not the input. Checking for aux-bus presense doesn't seem like a future-proof idea granted that bindings file explicitly mentions a
<lumag>
possibility of using it for DP too. Checking for the panel node also seems like a hack, especially because a panel can be under aux-bus or it can be a platform-bus node. Do we have any sensible solution in the DRM field?
simondnnsn has joined #dri-devel
dorcasli_ has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
<dianders>
lumag: Can you explain why `next_bridge->type` won't work in more detail? This is what Laurent came up with for `ti_sn_bridge_probe()`...
<lumag>
dianders, because that type represents the output of the bridge.
<lumag>
So for eDP-to-anything it will be that anything
<lumag>
So we need next_bridge->input_type of some kind
<lumag>
We can probably add it, but looks like a bit of overkill
<dianders>
lumag: Ah, got it. I guess you could do what `ti_sn_bridge_probe()` does and assume that if the next bridge is "DisplayPort" then you're full DP. Otherwise you're eDP. I guess I'd imagine most of the cases of conversion are for internal displays?
<lumag>
Then we'd need to fix all the interim bridges to be DisplayPort too.
<lumag>
dianders, is it safe to configure the PHY to eDP mode before probing AUX bus?
<lumag>
As we don't have next_bridge before aux-bus being probed anyway
<lumag>
This wouldn't be a question, but dp-aux-bus.yaml explicitly mentions that it can be repurposed to handle DP too.
kts has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
<dianders>
lumag: To be fair `dp-aux-bus.yaml` is just speculating that it could later be extended. Right now it's always eDP. FWIW from the yaml file you could safely assume that if your AUX bus has a "panel" child that it's eDP, right?
<lumag>
dianders, yeah, but we should keep old platform panel-edp devices in mind and remain compatible
<lumag>
So, do you think that for now we can safely assuem aux-bus => eDP
<lumag>
so it should be (!aux_bus && next_bridge->type == DP) => DP
<dianders>
lumag: Yeah, I think that would be OK. ...but if you wanted to be safe you could say "AUX bus + panel node under the AUX bus => eDP"
sgruszka has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
Leopold_ has quit []
<dianders>
lumag: Or just a comment next to it saying that if aux bus ever needs to be used for eDP we can check the panel node...
<lumag>
dianders, ah. And the 'panel' is a part of the bindings, so it will always be like that
<dianders>
lumag: exactly
<dianders>
lumag: Even so far as to be a "required" property. ...and the yaml file says that if it was used for DP later it would list a connector instead of a panel.
Leopold_ has joined #dri-devel
<lumag>
dianders, thanks!
balrog has quit [Quit: Bye]
<lumag>
dianders, should we care about panel-edp on a platform bus?
<lumag>
Or such DTs are long gone?
simon-perretta-img has quit [Ping timeout: 480 seconds]
<dianders>
lumag: IMO we shouldn't care about in the MSM eDP driver. If my memory serves, the eDP support in the MSM eDP driver is _newer_ than the concept of putting the panels on the AUX bus. That means that there _should_ be no old device trees out there that put their panel on the platform bus. The only reason I'm aware of to support the platform bus for eDP panels is backward compat.
<lumag>
yep
<lumag>
ack, thank you!
simon-perretta-img has joined #dri-devel
anujp has joined #dri-devel
tonyk has joined #dri-devel
sravn has quit [Quit: WeeChat 3.5]
Leopold_ has quit []
Company has joined #dri-devel
Leopold_ has joined #dri-devel
warpme has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
i509vcb has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
<Ermine>
Is Mesa NIR an alternative to LLVM?
dorcaslitunya has joined #dri-devel
<kisak>
alternative for what exactly?
simon-perretta-img has quit [Ping timeout: 480 seconds]
<Ermine>
Iiuc mesa uses llvm to compile shaders, so is nir does the same thing?
<gfxstrand>
Only for AMD and LLVM/lavapipe. Everything else uses NIR and a custom back-end compiler
<gfxstrand>
Describing NIR as an LLVM alternative wouldn't be the worst comparison
<psykose>
amd also has ACO as a llvm-free replacement now, if you build it that way
simon-perretta-img has joined #dri-devel
<kisak>
everybody with a non-ancient GPU gets their shaders run through at least some of the common set of optimizations with NIR these days, right? After the optimization passes it gets handed to the backend compiler to be converted into hardware specific bytecode, which is where LLVM might be involved.
<gfxstrand>
Correct. Where LLVM is used in mesa, we treat it as a back-end, not as the primary optimizer
<Ristovski>
Speaking of, is there a better way to dump RADV shaders apart from using RADV_DEBUG=shaders?
<gfxstrand>
Depends on your use case
<Ristovski>
General debugging - more specifically, I would like to make sure my shaders are emitting the right/expected instructions. Not sure if there is a better to get the dumps from within the program itself. Otherwise, I guess I could make a small prog that does nothing but compile shaders and write a wrapper that captures the stdout output
benjaminl has quit [Ping timeout: 480 seconds]
<gfxstrand>
VK_KHR_pipeline_executable_properties
<gfxstrand>
It's already integrated with RenderDoc so you can look at any pipeline and look at the assembly dump from right there in RenderDoc
<gfxstrand>
Or you can use it yourself from your app if you'd prefer
KDDLB0 has quit []
<Ristovski>
Oh? I was under the assumption that RenderDoc needed Radeon GPU Analyzer to do the disassembly
<gfxstrand>
Nope. It gets the assembly straight from RADV
<gfxstrand>
I think it also has a radeon GPU analyzer thing
<Ristovski>
Aaah, that's cool. Thanks!
<gfxstrand>
But VK_KHR_pipeline_executable properties should also work. It also works with most Mesa drivers so it'll work on NVK, the Intel driver, etc.
KDDLB0 has joined #dri-devel
<Ristovski>
Yeah not sure how I missed the fact that it can do what I am looking for
Leopold_ has quit []
warpme has joined #dri-devel
Leopold_ has joined #dri-devel
dogukan has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
<Ermine>
gfxstrand: thank you!
simon-perretta-img has joined #dri-devel
benjaminl has joined #dri-devel
balrog has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
tlwoerner has joined #dri-devel
simon-perretta-img has joined #dri-devel
<airlied>
bcheng: yeah ffmpeg vs new khr api
warpme has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Leopold_ has quit [Read error: Connection reset by peer]
<bcheng>
airlied: are your fixes in ffmpeg or radv? when I last checked the reason it wasn't working was that ffmpeg was sending many references, even if they were pointing to the same resource
Leopold_ has joined #dri-devel
<DemiMarie>
Are there any circumstances under which a CPU mapping of VRAM can be revoked? “Revoked” meaning that subsequent accesses fault or no longer point to the same physical memory.
<DemiMarie>
This could be a problem for Xen grant-based virtio, because there is no way to force a Xen guest to relinquish its mappings.
<DemiMarie>
(short of tearing down the guest, obviously)
<airlied>
bcheng: I haven't fixed it yet :-P
anujp has quit [Ping timeout: 480 seconds]
<bcheng>
well you said you made some progress, was just wondering what that was
junaid has joined #dri-devel
dorcaslitunya has quit [Remote host closed the connection]
Leopold_ has quit []
anujp has joined #dri-devel
Leopold has joined #dri-devel
dorcaslitunya has joined #dri-devel
dorcaslitunya has quit [Remote host closed the connection]
dorcaslitunya has joined #dri-devel
<airlied>
bcheng: oh I was fixing the ffmpeg side so far
junaid has quit [Remote host closed the connection]
dorcaslitunya has quit [Remote host closed the connection]
ninjaturtle has joined #dri-devel
<Ristovski>
Last time I looked into Vulkan video there was some intricacy that made it memory inefficient, has that been addressed since? (extremely out of the loop on vk video :/)
<CounterPillow>
that sounds like an extremely made up concern
<marex>
hey uh , I am rolling me an PCIe FPGA experimental setup and I need a continuous buffer on x86 machine for that to work ... on ARM this is fine with drm_gem_dma_create() , but on x86 this seems unavailable ?
<Ristovski>
> This is a problematic mode, as you have to allocate all references you need upfront, even if they're never used. Which, for 8k HEVC video, is around 3.2 gigabytes of Video RAM. Older AMD hardware requires this.
<marex>
or rather, on x86, there is no CMA enabled by default , there is the SHMEM allocator which ... for this hardware ... is not really good
<mareko>
karolherbst: you can push to my MR
jkrzyszt has quit [Ping timeout: 480 seconds]
<Ermine>
Ristovski: I wonder which hardware is meant by 'older'
<Ristovski>
Ermine: Supposedly hw that doesn't support VK_VIDEO_CAPABILITY_SEPARATE_REFERENCE_IMAGES_BIT_KHR
<airlied>
pre navi21
<Ristovski>
heh, "older"
<Ristovski>
I'd have guessed like pre GCN5 or something :P
<bcheng>
Ristovski: that's not a vulkan video problem, that's due to HW design
benjaminl has quit [Remote host closed the connection]
<ninjaturtle>
https://www.w3.org/TR/exi/ is the hack that likely makes things work without scala or signal collect or any of the external compression provider lib on openmath. This document needs to be read, hdt is modeled after that. https://oa.upm.es/37158/1/INVE_MEM_2014_198918.pdf , they have rich documentation as to what this interface does.
<Ermine>
interesting design...
<Ristovski>
bcheng: Indeed, back then when I read that post I didn't realize that and thus had been carrying that faulty assumption up until now
<Ermine>
guess I should pick rdna 3 card or newer next time
<Ristovski>
How is that even implemented in hw? What exactly did navi21 gain that makes this possible?
<bcheng>
Ristovski: There's a HW block inside the decode engine that fetches the reference data from memory. At a minimum there needs to be more HW registers to assign addresses for separate references, whereas previously a base address would have been enough. Although there's probably more to it
<bcheng>
anyway H.264 and H.265 SPS has information about the max number of references in the stream, ideally encoders would actually make that mean something so that the decoder can allocate the minimum required
fab has quit [Quit: fab]
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<ninjaturtle>
well w3c has many of those, turtle carries similar compression, but it much looks like the dictionaries can be left to xml through exi, really there's many specs i expect json to have something similar too.
<Ristovski>
bcheng: Hmm, are these decode engines separate (and thus vk specific?) from what's used in let's say VA-API with VCN?
rsripada has joined #dri-devel
<Ristovski>
(I'm failing to understand how this is a hw limitation on vk and not on vaapi for example)
<bcheng>
Ristovski: it is a limitation for vaapi, thats why I said its not a vulkan video problem
<bcheng>
vaapi just hides the fact that you have to allocate a big array, the driver does it for you
<Ristovski>
Aaaaah, now it clicked :)
<Ristovski>
See, I was under the assumption that it somehow automagically worked on vaapi but not on vulkan
<Ristovski>
thanks for the explanation, makes sense now
simon-perretta-img has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
<ninjaturtle>
i wonder if that openmath turned out to have mit license requirement , is a show stopper for anyone, there are more such libraries as openmath is , i dig a bit to in those, if something alike on sets or sequences/dicts can be found as suchthat function.
simon-perretta-img has joined #dri-devel
benjaminl has joined #dri-devel
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
<karolherbst>
mareko: pushed
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
ninjaturtle was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
Leopold has quit [Ping timeout: 480 seconds]
sudeepd has joined #dri-devel
sudeepd_ has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<marex>
is there something convenient on x86 that would give me a continuous buffer for PCIe DMA ?
<marex>
I mean, something like drm_gem_dma_create() which is available with CMA on ARM, but not on x86
Leopold has joined #dri-devel
<tnt>
marex: hugepages ?
Leopold___ has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
Leopold has quit [Ping timeout: 480 seconds]
krushia has quit []
glennk has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
guludo has quit [Quit: WeeChat 4.2.1]
<marex>
tnt: but doesn't that mean throwing away the CMA backed allocator and then switching over to SHMEM backed by hugepages ?
<DemiMarie>
Are there any conditions under which DRM will revoke user access to a PCIe BAR?
<marex>
at least that is what i915 seems to be doing
<marex>
but I was under the impression that with THP , there is no guarantee the allocation will be continuous , or is there ?
<marex>
I am not that deep in the hugepages, I just recall there was something about it
<DemiMarie>
marex: why do you need a contiguous buffer? No-IOMMU systems?
<Ristovski>
not sure, this is kinda beyond me tbh
<marex>
DemiMarie: ummmm ... wait ...
<marex>
DemiMarie: could it be that I can use IOMMU to make a non-continuous buffer look continuous toward the FPGA using IOMMU ?
<DemiMarie>
marex: yes
<DemiMarie>
at least in theory
<marex>
DemiMarie: do you have a hint what should I grep for ?
<DemiMarie>
I don’t know what the appropriate kernel interfaces are
<DemiMarie>
marex: no
<marex>
heh
<DemiMarie>
Also unmapping IOMMU buffers is very expensive
<marex>
but this approach does sound familiar at laest
<marex>
hmmmm, right, because you have to talk the page tables of every device or something like that, right ?
<DemiMarie>
Best practice for using an IOMMU is to map all the buffers you need at startup and never use them for anything but I/O.
<DemiMarie>
IOMMUs have TLBs and flushing them is hilariously slow due to a bad specification.
<marex>
DemiMarie: I kinda need continuous DMABUFs to go in and out
<marex>
DemiMarie: or something along the lines, with the CMA it was easy
<marex>
seems on x86 it is ... harder
<DemiMarie>
marex: port CMA to x86?
<DemiMarie>
I know nothing about the kernel interfaces, sorry. I do know something about what the hardware can do, though.
<marex>
OK
<DemiMarie>
But my interest comes from the security perspective
sudeepd has quit [Ping timeout: 480 seconds]
sudeepd has joined #dri-devel
<HdkR>
I do love hardware that optimizes contiguous mapped pages
<DemiMarie>
What happens to pages mapped with vkMapMemory when I get VK_ERROR_DEVICE_LOST?
<DemiMarie>
Specifically, what happens if VK_ERROR_DEVICE_LOST happens on one thread while another thread was accessing the pages? Will that cause SIGSEGV or SIGBUS?
<gfxstrand>
Depends on how bad the device loss is
<DemiMarie>
Are there any cases where the kernel will unmap the pages out from under userspace?
<karolherbst>
it was considered for the eGPU use case
<gfxstrand>
It's theoretically possible for the gpu to just vanish before the kernel has the chance to fix your maps
<DemiMarie>
I’m actually fine with userspace (really a guest VM) accessing a BAR of a nonexistent PCI device
<gfxstrand>
But in the classic "the card hung" scenario, you should still have your maps
<karolherbst>
should trigger a SIGBUS, no?
<gfxstrand>
I would think
<DemiMarie>
The bad case is where the kernel tries to unmap the memory out from under userspace
<karolherbst>
I think for the eGPU case something more graceful was considered, like replacing it with zero maps or something like that? dunno.. the discussion was old :D
<DemiMarie>
Because under Xen, unmapping memory that has been shared with another Xen VM is fundamentally cooperative
<gfxstrand>
That's fine. The kernel can re-map it to zero pages or something.
<gfxstrand>
The bad case is where someone unplugs their eGPU and the PCI device is just gone
<DemiMarie>
gfxstrand: Under Xen, you can’t!
<DemiMarie>
Not for memory shared with guests
<gfxstrand>
That's entertaining
<karolherbst>
guess they get a SIGBUS then
<karolherbst>
DemiMarie: why can't we though? it's not like this is RAM, this is device memory and if the device is gone, so is the memory
<karolherbst>
there is no "freed" memory, it's gone memory in the case of the GPU going boom
<DemiMarie>
So device physically going away isn’t a problem, so long as the system faults rather than just hanging forever.
<karolherbst>
yeah.. clients will get a SIGBUS
<DemiMarie>
But what if the user plugs the device back in? Those mappings could still be there.
<karolherbst>
nah, they are gone
<DemiMarie>
what do you mean? where do the page tables now point?
i509vcb has quit [Quit: Connection closed for inactivity]
<DemiMarie>
or are physical addresses never reused?
<karolherbst>
so I don't know if you can do it quickly enough, but normally if the PCIe decide is gone, the connection is marked as such on a kernel level
<karolherbst>
*device
<karolherbst>
however I don't really know _if_ you can make the application access memory after the device goes back in, but that's kinda unlikely I would say
<DemiMarie>
what happens to those accesses?
<karolherbst>
at least when I was looking into eGPU things, the bigger concern was the system just going down entirely
<karolherbst>
they should SIGBUS
<karolherbst>
and I say should, because anything else I'd consider a bug
<DemiMarie>
will the physical address space backing them ever be reused?
<karolherbst>
I don't think that's even relevant here
<karolherbst>
the kernel should just nuke all entries after the device was detected to be gone
<karolherbst>
and I _think_ it does
<DemiMarie>
under Xen, it can’t, which probably means that any idea of grant-based virtio-GPU is dead
<karolherbst>
why can't it?
<DemiMarie>
Because there is no hypercall that would allow it
<karolherbst>
well.. sounds like Xen misses a feature then?
<karolherbst>
how does it all work for hotpluggable PCIe devices then?
sima has quit [Ping timeout: 480 seconds]
<DemiMarie>
The underlying operations are “let domain A map page X of my memory” and “stop letting domain A map page X of my memory, failing if page X is still mapped”
<DemiMarie>
karolherbst: I agree with you :)
<karolherbst>
I mean.. it would be surprising if the hypervisor couldn't nuke pages
<karolherbst>
but maybe that's just not a considered use case?
<karolherbst>
dunno
<DemiMarie>
# CONFIG_HOTPLUG_PCI is not set
<karolherbst>
yeah well...
<DemiMarie>
not a considered use-case
<DemiMarie>
I think
<karolherbst>
don't hotunplug your pcie devices then :P
<DemiMarie>
or maybe technical debt
<karolherbst>
but yeah... PCIe device needing a full reset.. mhhh
<karolherbst>
probably the same situation from a high level pov
<DemiMarie>
nuking pages is not a good idea because the guest might not be able to handle the fault, but pointing them at a per-domain scratch page should be fine
<DemiMarie>
ouch
<karolherbst>
yeah.. might make sense to revive the old threads on how to deal with eGPUs
<DemiMarie>
does KVM’s MMU support nuking PTEs?
<karolherbst>
it's _kinda_ the same problem
DavidHeidelberg has quit [Ping timeout: 480 seconds]
<karolherbst>
I have no idea, but it would kinda surprise me if there is no handling for SIGBUS situations, but dunno
DavidHeidelberg has joined #dri-devel
kzd has quit [Quit: kzd]
mvlad has quit [Remote host closed the connection]
<DemiMarie>
SIGBUS is just delivered to the guest as-is.
<DemiMarie>
Or rather the underlying hardware fault is delivered.
<karolherbst>
mhh right.. if the device is assigned to the guest
<karolherbst>
so it's the guests problem to nuke pages for their clients
<karolherbst>
or signal SIGBUS on access
anujp has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
sudeepd_ has joined #dri-devel
<DemiMarie>
so in this case only some VRAM is exposed to the guest
<DemiMarie>
and so the host driver is responsible for unmapping the pages, which it can’t do, so this is a limitation in Xen that needs to be addressed.
<airlied>
marex: use an iommu :-)
sudeepd has quit [Ping timeout: 480 seconds]
<airlied>
DemiMarie: we nuke userspace mappings of device memory all the time
<DemiMarie>
airlied: ouch!
<airlied>
it's how we migrate things from system memory to vram etc
<airlied>
and deal with visibile vs invisible vram
<DemiMarie>
How bad would it be to never migrate stuff?
KDDLB0 has quit []
<DemiMarie>
For context: a Xen grant is basically a FOLL_LONGTERM pin by a driver that doesn’t support MMU notifiers and instead requires a pinned reference to the memory.
<airlied>
yeah not getting involved with Xen
<DemiMarie>
bad experiences in the past?
KDDLB0 has joined #dri-devel
<airlied>
my employer has no interest in it
<DemiMarie>
Mine does, but I don’t expect you to know anything about Xen.
Leopold___ has quit [Ping timeout: 480 seconds]
<DemiMarie>
Hence the analogy
<airlied>
I know enough about Xen to know I don't want to know anymore :-)