ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Lucretia has quit []
sravn has joined #dri-devel
idr has quit [Quit: Leaving]
jhli has quit [Read error: Connection reset by peer]
chivay_ has joined #dri-devel
jhli has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
jhli has quit [Ping timeout: 480 seconds]
<agd5f>
mdnavare, yes, works fine
Koniiiik has quit [Server closed connection]
Koniiiik has joined #dri-devel
tjaalton has quit [Server closed connection]
tjaalton has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit []
chivay_ has left #dri-devel [#dri-devel]
chivay_ has joined #dri-devel
pH5 has quit [Server closed connection]
pH5 has joined #dri-devel
chivay_ has quit []
chivay_ has joined #dri-devel
mbrost has joined #dri-devel
haasn has quit [Server closed connection]
haasn has joined #dri-devel
mbrost_ has joined #dri-devel
mwalle has quit [Server closed connection]
mwalle has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
sagar_ has quit [Ping timeout: 480 seconds]
<alyssa>
daniels: I checked my log and there's a few fails in the CTS run noooooooo
<alyssa>
dEQP-GLES3.functional.fragment_ops.random.* with multisampling 4x
slattann has quit []
<macromorgan>
getting this error on mainline master, not sure what it could be: UBSAN: shift-out-of-bounds in drivers/gpu/drm/panfrost/panfrost_mmu.c:70:35 \n shift exponent -1 is negative
<icecream95>
Those two comments (one in panfrost_mmu.c, one in fls.h) seem to disagree...
<HdkR>
Guess it should error when someone tries locking a zero sized region :)
<macromorgan>
anything I can do to help debug it better?
<HdkR>
I don't do kernel dev, no idea from me.
<mdnavare>
agd5f: And it works with both X and Wayland compositors right? So the work is mostly in the kernel driver to have some kind of lmem shadow copies for the smem buffer from which the primary dispaly is scanning out of and then copying over to shadow buffer in lmem
<agd5f>
mdnavare, yeah works with X and wayland. I think userspace generally deals with any extra copies that are required
jhli has joined #dri-devel
<mdnavare>
agd5f: Yes but proper import should happen from igpu to dgpu should happen at the kernel level and then per frame copying by userspace 3D driver
<mdnavare>
?
<airlied>
mdnavare: userspace should handle all the copies
<airlied>
for igpu sharing to dgpu with X.org there should be a main igpu scanout buffer covering the two displays, a shared igpu/dgpu the size of the dgpu scanout, and a dgpu vram buffer
<airlied>
call them a, b, c
<airlied>
userspace should be ensuring copies from a->b and b->c happen
<airlied>
scanout for igpu should be from a, scanout for dgpu should be from c
jessica_24 has quit [Quit: Connection closed for inactivity]
<airlied>
mdnavare: though looking at the X server there is a check for the i915 kernel driver
* airlied
should check xserver master
<airlied>
mdnavare: yup still there, that might be a bug to fix for dgpus
<airlied>
if (!strncmp("i915", version->name, version->name_len)) {
<mdnavare>
airlied: I am back sorry was finishing up dinner
jhli has quit [Remote host closed the connection]
sagar_ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
Adrinael has quit [Server closed connection]
Adrinael has joined #dri-devel
<mdnavare>
airlied: So for i915, it actually doesnt do the reverse PRIME mode?
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
slattann has joined #dri-devel
<mdnavare>
thellstrom: I have been looking at some of your code on gem object migrate and pinning, I am trying to understand what exactly happens when we say buffer migrate from lmem to smem and pinned to smem and how that differs from importing a buffer on igpu from dgpu?
<airlied>
mdnavare: yes you'd have to test with an xserver that line removed
sagar_ has quit [Ping timeout: 480 seconds]
<mdnavare>
airlied: Okay and with X server then supporting reverse prime, that will enable the a to b and b to c copies then
<mdnavare>
Is that the expectation?
Duke`` has joined #dri-devel
<airlied>
mdnavare: yes that should be the expectation
<mdnavare>
since by default now render will be happening on igpu and so it would have the buffer allocated on smem, then that will need to be copied to lmem + smem shadow buffer and then dgpu vram buffer for scanout
<mdnavare>
airlied: With reverse prime offload allowed, will that all happen seamlessly?
<airlied>
mdnavare: should do
<mdnavare>
airlied: Also if we set the DRI PRIME =1 globally then it should always be c -> b and b-> a copies right?
mattrope has quit [Remote host closed the connection]
<mdnavare>
and that should light up both displays in extended mode without the Xserver change?
<airlied>
mdnavare: DRI_PRIME shouldn't matter for this
<mdnavare>
I thought that is what will decide whether it is prime or reverse prime offload mode
<airlied>
it shouldn't be affecting that, unless it's by accident
<mdnavare>
probably then DRI PRIME only gets used in 3D for deciding whether the buffer should be allocated in lmem or smem
<mdnavare>
airlied: Also Dave I am trying to understand what exactly happens when we say buffer migrate from lmem to smem and pinned to smem and how that differs from importing a buffer on igpu from dgpu? Can you help me better understand this
<airlied>
in these cases the buffers shouldn't be migrating at all
<airlied>
maybe once at startup
<airlied>
if you import a buffer on the igpu from the dgpu then it will have to be in smem, how it gets there is up to the kernel
<mdnavare>
airlied: What does it mean by buffer migration?
<mdnavare>
airlied: I mean what is the fundamental differnce between buffer import and buffer migrate
<airlied>
mdnavare: buffer import is the dma-buf operation, buffer migration is an internal driver thing
<mdnavare>
airlied: But what does the driver physically do to the buffer when it says migrate
<airlied>
just copies the contents from vram to system ram
<airlied>
or vice-versa
<mdnavare>
airlied: Okay so Case 1: iGPU is render, it will allocate a buffer on SMEM and if dGPU is displaying or scanning that out, what is the import/migrate/copy flow?
camus1 has joined #dri-devel
danvet has joined #dri-devel
<airlied>
mdnavare: X server will create a shared igpu/dgpu buffer, and a dgpu buffer for scanout
<airlied>
and it will execute the copies
<airlied>
the kernel might have to move the dgpu buffer to vram the first time it's set to scanout
<airlied>
depending on how it was allocated
<mdnavare>
airlied: where would it be typically allocated? Xserver will allocate it initially on smem only?
camus has quit [Ping timeout: 480 seconds]
<airlied>
the X server would ask gbm/egl whatever so it should know it's scanout and put in the right place from teh start
<airlied>
but I'm not guaranteeing the drivers doing the right thing
<mdnavare>
airlied: So if egl knows scanout is on dGPU, it will actually just allocate dgpu on LMEM/vram, then for every frame it just copies from igpu/dgpu shared buffer to dgpu?
<mdnavare>
and then it get scanned out?
<airlied>
mdnavare: yes
Thymo has quit [Server closed connection]
Thymo has joined #dri-devel
<mdnavare>
Thanks airlied, will try with the Xserver change if it fixes the extended mode issue
vivijim has quit [Read error: Connection reset by peer]
<mdnavare>
danvet: I think if the Xserver change works then we probably wont need any gem/display kernel changes to handle the extended mode on displays connected across IGPU +DGPU (like I had asked in the email)
leandrohrb2 has quit [Server closed connection]
leandrohrb2 has joined #dri-devel
xxmitsu has quit [Server closed connection]
xxmitsu has joined #dri-devel
JohnnyonF has joined #dri-devel
jhli has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
shadeslayer has quit [Server closed connection]
shadeslayer has joined #dri-devel
frieder has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
jhli has quit [Ping timeout: 480 seconds]
<thellstrom>
mdnavare: Did you get all the answers you needed from airlied, or is there something I can try to answer?
thellstrom1 has joined #dri-devel
rasterman has joined #dri-devel
Daanct12 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
thellstrom1 has quit []
thellstrom has joined #dri-devel
lynxeye has joined #dri-devel
<MrCooper>
agd5f: compositing is not required for Xorg PRIME secondary GPU scanout; the issue described by mdnavare could be a bug in the Xorg or kernel driver for the secondary GPU (airlied might have found it)
V has quit [Server closed connection]
V has joined #dri-devel
jkrzyszt has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
shfil has joined #dri-devel
xexaxo_ has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
i-garrison has quit [Server closed connection]
i-garrison has joined #dri-devel
pendingchaos has quit [Quit: No Ping reply in 180 seconds.]
pendingchaos has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
<MrCooper>
jekstrand: or since the code won't actually run on Windows, just #define DRM_FORMAT_MOD_INVALID <something appropriate> for that
pcercuei has joined #dri-devel
<dj-death>
jenatali: I'm struggling a bit to figure what package is providing the spirv-mesa3d-.spv.h file
<daniels>
dj-death: none - it's generated from the .spv provided by libclc which is part of llvm
<daniels>
it installs that into its libexecdir when you pass -DLIBCLC_TARGETS_TO_BUILD=spirv-mesa3d-
dllud has quit [Server closed connection]
dllud has joined #dri-devel
Daaanct12 has joined #dri-devel
<dj-death>
daniels: there is no way to generate it from mesa's meson ?
Daanct12 has quit [Ping timeout: 480 seconds]
thellstrom has quit [Quit: thellstrom]
thellstrom has joined #dri-devel
thellstrom has quit []
thellstrom has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
thellstrom has joined #dri-devel
flacks has joined #dri-devel
<daniels>
dj-death: to generate the .spv? no, you need to compile it from libclc
<daniels>
I mean Mesa could vendor the whole of libclc, or distribute a pre-built SPIR-V binary, but I can't see that exactly being popular
xexaxo_ has joined #dri-devel
<dj-death>
daniels: I just find it a bit odd that apparently we need the libclc source package to generate the file
frieder has joined #dri-devel
<daniels>
dj-death: mm, no? you build libclc (using cmake) and install it to wherever, it installs the generated .spv and pkg-config file to the prefix, then Meson uses pkg-config to discover the install location and wrap the .spv in a .h using xxd
<daniels>
but yeah, I mean at some point you do need to build libclc itself, given it's ... non-trivial
<daniels>
it's packaged as libclc in Fedora 35 and libclc-13 in Debian experimental
<daniels>
s/experimental/sid/
<dj-death>
ah okay
<dj-death>
I guess I'm unlucky that it's not shipping as part of libclc-13 from apt.llvm.org
shfil has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<zmike>
MrCooper: you found a hard bug :/
pochu has joined #dri-devel
mattrope has joined #dri-devel
<dj-death>
is kmscube more or less of a joke than vkcube?
pochu has quit [Ping timeout: 480 seconds]
<MrCooper>
zmike: sorry :)
<MrCooper>
just happened to notice it
slattann has joined #dri-devel
slattann has quit []
<CounterPillow>
What could cause a drm driver to probe but never call its bind?
<danvet>
EPROBE_DEFERREED
<danvet>
CounterPillow, if this is some random soc at least
<danvet>
usually means you didn't enable enough stuff in your Kconfig for the driver to fully load
<danvet>
or I'm confused about the problem
* danvet
interpolating a lot
<CounterPillow>
danvet: thanks, this is a random soc and we're currently trying to bludgeon a rough forward port of rockchip's vop2 into at least doing something
<CounterPillow>
^- is this possibly related? It does complain of a cyclic dependency with HDMI earlier on, but the probe function prints after this message
<ajax>
i find it suspicious that if i take out glx_arb_sync_control i have exactly 100 glx tests in piglit
<danvet>
CounterPillow, yeah that's EPROBE_DEFER
<CounterPillow>
Alright, thanks
<danvet>
it means not all parts of the driver are there
<danvet>
I think at least
<danvet>
I've never worked with this stuff for real, just watch others fail at it :-P
<danvet>
x86 doesn't have these cobbled-together devices that much
<CounterPillow>
Yeah :(
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
dongwonk has quit [Remote host closed the connection]
nchery has joined #dri-devel
frieder_ has quit [Remote host closed the connection]
slattann has joined #dri-devel
nirmoy has joined #dri-devel
pochu has joined #dri-devel
camus has joined #dri-devel
slattann has quit []
camus1 has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
<mdnavare>
danvet: On the extended mode thread / secondary GPU scanout as per airlied X should be creating a complete scanout buffer on smem, igpu + dgpu shared buffer of the size of dgpu scanout and then dgpu buffer for the scanout and then ensuring copies between a to b to c
<mdnavare>
danvet: So then do you suspect any more changes here on our kernel driver to handle this?
<mdnavare>
or everything handled in the userspace?
<mdnavare>
jekstrand : The concern you had had was that in this extended mode case, the smem buffer might be needed to be pinned in smem and lmem at the same time for scanout but I think if there are 3 buffers like what airlied said (smem buffer for the whole desktop content, igpu + dgpu shared buffer of size of dgpu scanout and then dgpu buffer and if userspace ensures copies between them we wont have this issue ) right ?
pochu has quit [Remote host closed the connection]
<alyssa>
...Wait
<alyssa>
glClearColor is dithered only if glEnable(GL_DITHER) is set at the time isn't it.
slattann has joined #dri-devel
<alyssa>
Ahhh
<danvet>
mdnavare, for igpu+dgpu we should only need 2 buffers
<danvet>
3 are needed for dgpu + dgpu
<danvet>
also the migration fix from jekstrand is still needed in DII I think
<danvet>
maybe check with mike ruhl on that, not sure
<MrCooper>
danvet: unless your dGPU can scan out from system memory, a separate shared buffer is required for iGPU rendering → dGPU scanout as well
<mdnavare>
danvet: MrCooper: Yes our dgpu cannot scanout from smem so thats why I think yes we would be needing that separate buffer
<MrCooper>
(or unless the dGPU happens to be able to consume the iGPU's main buffer, I guess)
Ahuj has quit [Ping timeout: 480 seconds]
<danvet>
MrCooper, yeah the 2 buffers only works if the igpu doesn't insist the scanout must be in stolen or something
<danvet>
which hasn't been the case for intel igpu ever since og i810
<danvet>
but I know amd igpu only lifted that recently
<MrCooper>
danvet: talking about *dGPU scanout*
<danvet>
MrCooper, yes
<danvet>
1 idgpu buffer, pinned into ram
<danvet>
1 dgpu buffer, pinned into vram
<jekstrand>
danvet: Yes, the migration fix is needed in DII. It still locksplats.
<MrCooper>
why are you talkig about iGPU scanout then? :)
<danvet>
dgpu does the blt job from the first to the 2nd
<danvet>
MrCooper, extended desktop I thought we're talking about, where you want the same desktop on both
<jekstrand>
danvet: The case that has me confused is what happens if a client renders on the dGPU, scans out on the dGPU, and then tries to import to an iGPU or a different dGPU.
<danvet>
jekstrand, fails at fd2handle
<MrCooper>
danvet: right, that's assuming the dGPU can read the iGPU's main buffer tiling
<danvet>
if you try to share after you've set it up as scanout
<jekstrand>
Ok, I guess that makes sense
<danvet>
if you do it other way round it should fail at addfb time (which we probably don't)
<danvet>
MrCooper, ah yes we also assume that
<jekstrand>
danvet: Actually, I think we might. We probably don't have IGTs for it, though.
<danvet>
ofc there's the slight problem of most compositors not having enabled drm_formats for intel, but oh welp
shfil has joined #dri-devel
<danvet>
jekstrand, the thing I'm wonder is whether an addfb should block pinning to smem already or not
<jekstrand>
MrCooper: dGPU reading iGPU's tiling will be a thing. :)
<alyssa>
jekstrand: When will you support Arm tiling?
<jekstrand>
alyssa: Not that iGPU. :P
<alyssa>
For when I use my DG1 card on my Chromebook
<alyssa>
:_p
<MrCooper>
jekstrand: same joke about AMD tiling :P
<jekstrand>
alyssa: I have considered teaching the mesa PRIME code about Intel X and Y-tiling, though.
<jekstrand>
Instead of doing vkCmdCopyImageToBuffer to do the blit, set up a compute shader that X-tiles the output and run that.
<jenatali>
We attempted to introduce a standard tiling layout into the industry so we could do better cross-adapter memory accesses
<jenatali>
We failed :(
<jekstrand>
Not sure how that'd work through the DRI layer but it'd be easy enough with the Vulkan WSI layer.
<jekstrand>
jenatali: We were right with you on it! Too bad we implemented it wrong at least 3 times. (-:
<jenatali>
Yeah I think you guys were the only ones who tried though
<jekstrand>
AFAIK, yes.
<MrCooper>
generic user space will probably need modifiers to determine if a special case with 2 buffers is possible, and fall back to 3 buffers if not
<jekstrand>
But if you also had it in WARP, that's two implementations. It's a standard!
pochu has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
<mdnavare>
danvet: MrCooper: jekstrand: So in the extended case, by default when only igpu is rendering and we need to scanout on both igpu and dgpu display, then it renders on igpu + dgpu buffer in smem, copies that to dgpu buffer for scanout on dgpu, no issues there right?
<mdnavare>
danvet: MrCooper:jekstrand: Problem is if we force dri prime for dgpu to render and want scanout on both igpu and dgpu then what happens?
<MrCooper>
iGPU composites dGPU client buffer contents to its main buffer, after that same as always
<MrCooper>
(that's the generic fallback case, fancy compositors might try to avoid the dGPU → iGPU → dGPU round-trip somehow)
<danvet>
not sure we use it for anything though :-)
<jekstrand>
danvet: Nope
<jekstrand>
danvet: We did. It was called Ys on SKL
<jekstrand>
But that's totally different from tile64 on DG2
<mdnavare>
MrCooper: so thatc omposited buffer will be in smem and be igpu + dgpu shared buffer and then copy again to dgpu buffer for scanout right?
<danvet>
jekstrand, and neither of them was the ms format?
<jekstrand>
danvet: Ys was the MS format, except we implemented miptails wrong.
<danvet>
hah lol
<jekstrand>
And then we implemented them differently wrong on CNL.
<danvet>
classic intel "we need dx9.0c for us pls" or whatever it was
<bnieuwenhuizen>
I think on the AMD side we actually support the MS format, I think it is our _S tiling
<jekstrand>
I've not R/Ed ICL to know if we finally got them right.
<MrCooper>
mdnavare: sounds right
<danvet>
bnieuwenhuizen, jekstrand I guess if we type up an igt that verifies it scans out or something we could add it
<danvet>
but also, probably way too much niche
<danvet>
need to get modifiers in general going better first
<mdnavare>
jekstrand: danvet: So atleast for getting the extended desktop case to work like it works on AMD, the existing X and Wayland compositors hsould handle it after removing the reverse prime = false for i915 in Xserver. No other driver work needed there?
<mdnavare>
danvet: jekstrand: Well ofcourse the gem migration fixes that jekstrand made but no new changes I guess
<mdnavare>
needed
<mdnavare>
jekstrand: danvet: So no arch changes/discussion on that is that correct
gouchi has joined #dri-devel
mbrost has joined #dri-devel
JohnnyonFlame has joined #dri-devel
hikiko_ has joined #dri-devel
hikiko_ has quit []
mlankhorst has quit [Ping timeout: 480 seconds]
hikiko_bsd has joined #dri-devel
xexaxo_ has joined #dri-devel
jhli has joined #dri-devel
Company has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
The_Company has quit [Ping timeout: 480 seconds]
pochu_ has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
<jljusten>
dj-death, daniels: hopefully the revert should only be short term. the issue is that https://apt.llvm.org/ wants to support buster, bionic (18.04), but they don't have llvm-spirv. the dev that owns things needs to split things up a bit to deal with that.
<jljusten>
jekstrand: almost have .spv files for debian/ubuntu...
pochu_ has quit [Ping timeout: 480 seconds]
<jekstrand>
jljusten: Ah
idr has joined #dri-devel
slattann has quit []
shfil has quit [Quit: Konversation terminated!]
<alyssa>
robclark: " nit, space before ( for iterator macros
<alyssa>
"
slattann has joined #dri-devel
<alyssa>
this is my preference as well (I think) but it's annoyingly different than kernel style :V
* robclark
disagrees with kernel style in a few areas..
* alyssa
nods
lynxeye has quit [Quit: Leaving.]
<jekstrand>
I don't put in that space
<robclark>
I kinda thing iterator macros should follow the same rule as `for`.. I think clang-format agrees with me on that one particular thing..
<zmike>
👎⛔🚫space🚫⛔👎
<jekstrand>
robclark: Yeah... I get that argument.
<dj-death>
jljusten: thanks for doing all that :)
<jljusten>
dj-death: now I know just how long it takes to build llvm. :) and, I know how to try to build llvm but have it break 1h into the build with no useful error message. (repeatedly :)
<jekstrand>
jljusten: Useful life skills!
<jekstrand>
jljusten: Especially that second one. :P
<macromorgan>
specifically those lines are setting the value of size to ~0UL, which I'm seeing as a -1?
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
<airlied>
jenatali: coming up with new tiling is gpu memory c9ntroller designers job security
<dj-death>
jljusten: I unfortunately know worse projects than llvm in terms of build time and ability to hang your machine just by the amount of memory required to compile some objects
<airlied>
linking llvm is the killer
<airlied>
esp doing ninja without setting then cmake opt to limit parallel links
gouchi has quit [Remote host closed the connection]
rasterman has joined #dri-devel
gouchi has joined #dri-devel
nirmoy has quit []
<jljusten>
the path for nixos .spv files appears to have even more obstacles :/ currently stuck on a macos build failure blocking the llvm-spirv update
<alyssa>
macromorgan: eyes
<alyssa>
macromorgan: ooh
gouchi has quit [Remote host closed the connection]
<alyssa>
writing a patch
<alyssa>
log2 minus 1..ok
gouchi has joined #dri-devel
<macromorgan>
cool... let me know if you want me to test it
<alyssa>
incidentally it looks like this code is buggy
<alyssa>
like, functionally buggy, not just theoretically
<alyssa>
s/theoretically/UBSAN-ily/
<alyssa>
at least on bifrost
<macromorgan>
Yeah, I've been running it on an Odroid Go Advance I use for development, but yesterday was the first time I tried anything silly like launching a GUI on it in several months.
JohnnyonFlame has joined #dri-devel
<alyssa>
doesn't apply to midgard
<alyssa>
wonder if kbase hanldes this?
<alyssa>
yep.
<alyssa>
robher: ^
<alyssa>
In bifrost-supporting kbase, there's the following define:
<alyssa>
kbase's `lock_region` rounds up to said minimum size, expressing the fact that bifrost can only lock 32kb regions at a time (not 4k like midgard)
<alyssa>
macromorgan: This is assuredly not the bug you were referring to 😅
<alyssa>
Regardless, I just refreshed my brain on the Mali MMU. Will write some patches fixing both issues. Thank you for the detailed report ❤️
<alyssa>
(but first I need to fix a compiler bug before dinner o'clock so I can get a CTS run overnight)
thellstrom has joined #dri-devel
pcercuei has quit [Quit: brb]
<robher>
alyssa: s/size_t/u64/ and maybe should be ~0ULL that's passed.
pcercuei has joined #dri-devel
<macromorgan>
thank you, appreciate it
<alyssa>
robher: Ack.
<robher>
Though 4GB may be enough as that was the max per AS (a should be enough(TM) max, not any h/w max).
<alyssa>
The other thing still applies
<alyssa>
Guess that just slipped through with all this code being written for midgard and then bifrost just getting bolted on and "it happens to work"?
* alyssa
would not have noticed if she hadn't gone researching AS_LOCKADDR
<dcbaker>
I've dropped it from the staging branch for the moment
JohnnyonF has joined #dri-devel
<alyssa>
dcbaker: I apologize in advance for all the stuff i'm cc'ing stable
<ngcortes>
qq; where can I find the latest drm-next kernel?
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<alyssa>
I really shouldn't have waited to do conformance testing until /after/ a branch point ...
<dcbaker>
alyssa: I'm still curious what you want to do about: "pan/bi: Use FABSNEG pseudo ops for modifier prop"
<dcbaker>
I don't think I can backport that properly
<alyssa>
"still" did we talk about this...?
<dcbaker>
I swear I messaged you about it?
<alyssa>
you might have I am very forgetful
<dcbaker>
maybe it was when I had become unregestered? D:
<kusma>
dcbaker: would you mind creating a ticket and assigning it to me about it? I'll take a look first thing in the morning...
<dcbaker>
kusma: sure
<alyssa>
dcbaker: For "FABSNEG", I would just drop that commit tbh
thellstrom1 has joined #dri-devel
<alyssa>
It does fix a real bug (and is visible on GL workloads), but the GL spec doesn't actually care, it's only interesting for vulkan which tightens the numerical requirements
<alyssa>
and we're not shipping panvk yet so no need to backport
<alyssa>
"Use FCLAMP pseudo op" ... this /does/ fix a real bug visible on 21.2 unfortunately.
<dcbaker>
I seem to remember that those were built on top of some non trivial changes
<imirkin>
karolherbst: yeah, dunno when i'll be able to mess around with ... anything, really
gouchi has quit [Remote host closed the connection]
pzanoni has quit [Quit: Coyote finally caught me]
<CounterPillow>
[ 0.540111] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
<CounterPillow>
[ 0.539194] rockchip-vop2 fe040000.vop: [drm:vop2_bind] I'm a real driver!
<CounterPillow>
Sometimes my debug prints make me laugh
<alyssa>
st_tile what is wrong
<karolherbst>
CounterPillow: ... oops
<imirkin>
CounterPillow: a real driver should handle the null pointer deref!
<icecream95>
alyssa: Stop distracting me, concentrating on school work during lockdown is hard enough even without you making me want to hack on Panfrost
<karolherbst>
icecream95: I think you have to just work on panfrost then
pcercuei has quit [Quit: dodo]
xexaxo_ has quit [Ping timeout: 480 seconds]
jhli_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
pochu has joined #dri-devel
jhli has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
jhli has joined #dri-devel
jhli_ has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
jessica_24 has joined #dri-devel
urja has quit [Read error: Connection reset by peer]
urja has joined #dri-devel
alanc has quit [Remote host closed the connection]
mbrost has quit [Quit: Leaving]
alanc has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<alyssa>
dcbaker: Okay, I finished up the bug fixes I started in Mesa
<alyssa>
I guess I can see about backporting things. idk. I have some big bug fixes queued on top of what's already there...
iive has quit []
pzanoni has joined #dri-devel
<karolherbst>
alyssa: I let others do the backporting for me :O
<karolherbst>
just apply Fixes tags and things get backported magically on their own :p
<alyssa>
karolherbst: these are nontrivial backports.
<pinchartl>
is git.fd.o down again, or is it just me ?
<karolherbst>
works here
<pinchartl>
sounds like the definition of "it's just me" then
<pinchartl>
can you fetch from git://anongit.freedesktop.org/drm/drm ?
<imirkin>
cgit (and thus anongit) appears broken
<imirkin>
daniels: --^
Hello71 has joined #dri-devel
<karolherbst>
pinchartl: ohh wait.. I tried the wrong thing