ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<jekstrand>
Doesn't look like it. Occlusion queries are doubled in every test. WHY?!?
<airlied>
you enabled oq for some meta path?
<jekstrand>
Maybe?!?
<jekstrand>
IDK how I would have done that
<jekstrand>
Actually....
<jekstrand>
Nope. No Begin/EndRendering happens inside a Begin/EndQuery
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
<zmike>
implicit clears
<jekstrand>
Maybe?
<zmike>
shame the cts tests for it haven't landed yet
<zmike>
then you'd have simpler ones to verify with
* jekstrand
looks
co1umbarius has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
<jekstrand>
Nah, that can't be it. implicit clears happen as part of BeginRendering and that completes before BeginQuery
<jekstrand>
Though I guess if I'm not stalling somewhere I should, maybe it's getting picked up in the query results?
<jekstrand>
That's actually not a terrible theory
<zmike>
time to throw in the ol' sledgehammer to test with
hch12907 has joined #dri-devel
nchery has joined #dri-devel
<jekstrand>
Time for supper, actually.
bschiett has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
janesma has quit [Quit: Leaving]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
khfeng has joined #dri-devel
jimjams has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<kisak>
What's with this configure-time subproject downloading stuff for directx-headers in mesa? It's strange it's not just a regular dependency. Does any other mesa dependency work that way?
<jekstrand>
It's a meson wrap. Everything required for Windows except LLVM is also available as wraps. Stuff required for Linux drivers goes through regular deps. Anything required for both can be done both ways[
<kisak>
okay, compensating for the lack of a proper package manager on Windows makes sense to me.
mclasen_ has quit [Ping timeout: 480 seconds]
hch12907 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
hch12907 has joined #dri-devel
Company has quit [Quit: Leaving]
heat_ has quit [Ping timeout: 480 seconds]
idr has quit [Quit: Leaving]
aravind has joined #dri-devel
<airlied>
karolherbst: buffer_offset_size doesn't seem correct to me for region calcs in rusticl
Duke`` has joined #dri-devel
<airlied>
it's taking a buffer with row pitch 672 and region 1, 21, 1, that region size would be 672, and it reports 1345 which is 1 * pitch + 21 * row_pitch + 1 * image_pitch
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
hch12907 has quit [Remote host closed the connection]
<airlied>
karolherbst: I think you don't bounds check origin/region properly either :-)
hch12907 has joined #dri-devel
<airlied>
there are some piglit tests to test that, cl-api-enqueue-fill-image
hch12907_ has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: ah the calcs are just wrong because the values are illegal and not being caught
Daanct12 has quit [Read error: Connection reset by peer]
<airlied>
at least I think that might be it
<karolherbst>
I think I fixed it up at some point though... this is all very annoying to get right
<karolherbst>
but yeah.. I might not error check everything yet :)
slattann has joined #dri-devel
AndrewR has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: the annoying part is, that most of the fails are either ignored error or piglit being wrong, so alwyas keep that in mind :P
<karolherbst>
piglit being wrong as in it also fails on intel CL e.g.
<airlied>
karolherbst: these piglit tests pass on clover fine
<airlied>
I'm just comparing fails between clover and rusticl
<karolherbst>
sure
<karolherbst>
so?
<karolherbst>
:P
<karolherbst>
I looked at all the fails, and they are either rusticl not checking errors or piglit being wrong
<airlied>
surprised not validating inputs doesn't crash or overrun memory
<airlied>
radeonsi asserts on a lot of those illegal things
<karolherbst>
I hope I didn't mess up mapping memory
<karolherbst>
piglit is just... weird in some tests as it requires/depends on stuff the spec never promises
<karolherbst>
even with a commend in the source "ohh this only passes on clover"
<karolherbst>
after running into that multiple times I got annoyed and ignored piglit :P
<airlied>
I think most of them will pass once rusticl validates inputs and throws errors properly
<karolherbst>
yeah
<karolherbst>
that's the part where I was too lazy :D
<karolherbst>
I think I fixed all the real issues though
<airlied>
now I gotta figure out load_work_dim
<karolherbst>
that's this weird AMD abi issue, isn't it?
<airlied>
I made clover load it for me before
<airlied>
nope
<airlied>
I'm not using abi anymore since I'm avoiding llvm
<airlied>
but I still need to pass work dimensions in as inputs
<karolherbst>
ehh...
<karolherbst>
wait..
<karolherbst>
which piglit tests hits it?
<airlied>
this is cts test
<karolherbst>
mhh I see
<airlied>
./basic/test_basic work_item_functions
<airlied>
have to see if I can handle it on the driver side
<karolherbst>
I am confused on why that's not an issue on iris or llvmpipe
<karolherbst>
ohh
<karolherbst>
iris handles it
<karolherbst>
and so does lp
<airlied>
yeah iris shoves it after the kernel inputs
<airlied>
just seem silly for each driver to end up doing that
<karolherbst>
airlied: yeah soo... for now I assume all drivers got the same "internal args", but I might have to rework this assumption and allow rusticl to handle some of it? dunno
<airlied>
I wrote lowering for clover to just stick it on the end
<karolherbst>
adding those args is quite trivial though
<karolherbst>
Just add an InternalKernelArgType deal with the code :P
<karolherbst>
mhh
<karolherbst>
I guess if no hw can support it anyway, I can also just handle it inside rusticl
<karolherbst>
airlied: I probably won't look into any of this this week, because bank holiday and I am off Friday as well :P
<karolherbst>
if you got anything else to work, you can throw me a branch and I deal with the rest myself, now that I got an AMD card
<airlied>
karolherbst: yeah I'm just wandering around seeing what's broken
<karolherbst>
you could run it with my runner and get a nice report :P
hch12907_ has quit [Ping timeout: 480 seconds]
<karolherbst>
but I can do that as well
<karolherbst>
anyway, I'll be off for now, but if you throw me a branch I try to integrate it into my rusticl one and let others test it as well :P
flto_ has joined #dri-devel
guru_ has joined #dri-devel
<karolherbst>
a lot of users are waiting for it :D
abhinav__1 has joined #dri-devel
nikitalita482 has joined #dri-devel
vyivel_ has joined #dri-devel
ifreund_ has joined #dri-devel
sumoon_ has joined #dri-devel
Karyon has joined #dri-devel
sarnex_ has joined #dri-devel
kathleen___ has joined #dri-devel
jhugo_ has joined #dri-devel
neoXite___ has joined #dri-devel
narmstrong_ has joined #dri-devel
hfink_ has joined #dri-devel
cengiz_io_ has joined #dri-devel
zzag_ has joined #dri-devel
reduz_ has joined #dri-devel
tchar_ has joined #dri-devel
MTCoster_ has joined #dri-devel
CosmicPenguin_ has joined #dri-devel
vjaquez has joined #dri-devel
jstultz_ has joined #dri-devel
jimjams_ has joined #dri-devel
seanpaul__ has joined #dri-devel
zmike_ has joined #dri-devel
bluebugs has joined #dri-devel
austriancoder_ has joined #dri-devel
krushia_ has joined #dri-devel
jessica_246 has joined #dri-devel
mmenzyns_ has joined #dri-devel
ogabbay_ has joined #dri-devel
robink_ has joined #dri-devel
dschuermann_ has joined #dri-devel
lstrano_ has joined #dri-devel
sh-zam has joined #dri-devel
zf_ has joined #dri-devel
ajax_ has joined #dri-devel
orbea1 has joined #dri-devel
jimjams has quit [synthon.oftc.net larich.oftc.net]
oneforall2 has quit [synthon.oftc.net larich.oftc.net]
ceyusa has quit [synthon.oftc.net larich.oftc.net]
vyivel has quit [synthon.oftc.net larich.oftc.net]
jessica_24 has quit [synthon.oftc.net larich.oftc.net]
abhinav__ has quit [synthon.oftc.net larich.oftc.net]
sagar_ has quit [synthon.oftc.net larich.oftc.net]
alanc has quit [synthon.oftc.net larich.oftc.net]
airlied has quit [synthon.oftc.net larich.oftc.net]
flto has quit [synthon.oftc.net larich.oftc.net]
jrayhawk has quit [synthon.oftc.net larich.oftc.net]
Lyude has quit [synthon.oftc.net larich.oftc.net]
andrey-konovalov has quit [synthon.oftc.net larich.oftc.net]
krushia has quit [synthon.oftc.net larich.oftc.net]
sarnex has quit [synthon.oftc.net larich.oftc.net]
zzag has quit [synthon.oftc.net larich.oftc.net]
jljusten has quit [synthon.oftc.net larich.oftc.net]
ajax has quit [synthon.oftc.net larich.oftc.net]
clever has quit [synthon.oftc.net larich.oftc.net]
demarchi has quit [synthon.oftc.net larich.oftc.net]
Lightning has quit [synthon.oftc.net larich.oftc.net]
radii_ has quit [synthon.oftc.net larich.oftc.net]
jolan_ has quit [synthon.oftc.net larich.oftc.net]
zf has quit [synthon.oftc.net larich.oftc.net]
sh_zam has quit [synthon.oftc.net larich.oftc.net]
xyene_ has quit [synthon.oftc.net larich.oftc.net]
seanpaul_ has quit [synthon.oftc.net larich.oftc.net]
lstrano has quit [synthon.oftc.net larich.oftc.net]
enilflah_ has quit [synthon.oftc.net larich.oftc.net]
Karyon_ has quit [synthon.oftc.net larich.oftc.net]
moa has quit [synthon.oftc.net larich.oftc.net]
anujp_ has quit [synthon.oftc.net larich.oftc.net]
Sachiel has quit [synthon.oftc.net larich.oftc.net]
ifreund has quit [synthon.oftc.net larich.oftc.net]
sumoon has quit [synthon.oftc.net larich.oftc.net]
mmenzyns has quit [synthon.oftc.net larich.oftc.net]
everfree has quit [synthon.oftc.net larich.oftc.net]
orbea has quit [synthon.oftc.net larich.oftc.net]
isinyaaa has quit [synthon.oftc.net larich.oftc.net]
kem has quit [synthon.oftc.net larich.oftc.net]
nikitalita48 has quit [synthon.oftc.net larich.oftc.net]
chadv has quit [synthon.oftc.net larich.oftc.net]
robink has quit [synthon.oftc.net larich.oftc.net]
austriancoder has quit [synthon.oftc.net larich.oftc.net]
reduz has quit [synthon.oftc.net larich.oftc.net]
neoXite__ has quit [synthon.oftc.net larich.oftc.net]
hfink has quit [synthon.oftc.net larich.oftc.net]
CosmicPenguin has quit [synthon.oftc.net larich.oftc.net]
jhugo has quit [synthon.oftc.net larich.oftc.net]
zmike has quit [synthon.oftc.net larich.oftc.net]
Lightsword has quit [synthon.oftc.net larich.oftc.net]
graphitemaster has quit [synthon.oftc.net larich.oftc.net]
Znullptr has quit [synthon.oftc.net larich.oftc.net]
cengiz_io has quit [synthon.oftc.net larich.oftc.net]
jstultz has quit [synthon.oftc.net larich.oftc.net]
ogabbay has quit [synthon.oftc.net larich.oftc.net]
tchar has quit [synthon.oftc.net larich.oftc.net]
kathleen__ has quit [synthon.oftc.net larich.oftc.net]
dschuermann has quit [synthon.oftc.net larich.oftc.net]
MTCoster has quit [synthon.oftc.net larich.oftc.net]
narmstrong has quit [synthon.oftc.net larich.oftc.net]
zmike_ is now known as zmike
Lightning has joined #dri-devel
airlied has joined #dri-devel
chadv has joined #dri-devel
Sachiel has joined #dri-devel
andrey-konovalov has joined #dri-devel
xyene has joined #dri-devel
sagar_ has joined #dri-devel
Lightsword has joined #dri-devel
austriancoder_ has quit []
Lightsword is now known as Guest357
chadv is now known as Guest358
isinyaaa has joined #dri-devel
<airlied>
karolherbst: it isn't integratable into rusticl
austriancoder has joined #dri-devel
enilflah has joined #dri-devel
<airlied>
I wouldn't even consider landing it until rusticl was in the tree
<emersion>
jekstrand: can we get a DRM cap to indicate whether the import/export ioctl is available?
<emersion>
i'd like to only enable explicit sync when it is, but checking for availabiliy is pretty non-trivial
<emersion>
i'd need to allocate a DMA-BUF just to check
<emersion>
(cc danvet)
<danvet>
emersion, or sysfs file in the dma-buf directory?
ppascher has quit [Quit: Gateway shutdown]
<danvet>
having that flag somewhere completely else feels a bit fishy
<emersion>
hm, right, this isn't tied to DRM after all
<danvet>
yeah
<emersion>
hm
<emersion>
is the dmabuf dir fixed?
<emersion>
ie, a constant?
apinheiro has quit [Ping timeout: 480 seconds]
<danvet>
emersion, should be /sys/kernel/dmabuf
<danvet>
I guess we could whack a has_import_export file in there
<emersion>
has_sync_file_import_export
<emersion>
yea
<emersion>
don't consider this blocking for landing the patch btw
<danvet>
maybe also a has_poll
<emersion>
if it helps i can type up the code
<emersion>
oh, not all dmabufs have polling support?
<danvet>
yeah we just missed the merge window, so if you type this up + wlroots patch plenty time to land it so it gets merged in linus' tree together
<danvet>
emersion, they all have, otherwise we couldn't put it into the dmabuf directory
<danvet>
but not all kernels have
<danvet>
but also I'm not sure how much we care about some of these older features
<emersion>
i plan to use this in wlroots for the vulkan renderer, independently of the explicit sync stuff
<emersion>
ack
<emersion>
yeah not sure has_poll is worth it
<danvet>
v3.17 <- first kernel with poll support
<emersion>
ah that's plenty of time
<danvet>
emersion, we could add it and backport to all stable kernels or so :-)
<emersion>
ah, i didn't consider this :P
<danvet>
but I'm not even sure how far back sysfs goes
<danvet>
so probably too much work
<danvet>
v5.15 for sysfs
<danvet>
I guess just assume poll exists and die if it doesnt
<danvet>
v3.12 for llseek i.e. size query support
<danvet>
emersion, maybe if you type this up include a kerneldoc that lists when some of this stuff got added
<emersion>
good idea
itoral has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
technopoirot has quit [Ping timeout: 480 seconds]
<javierm>
danvet, emersion: is the ability to import/export per driver or global ?
<emersion>
global
<javierm>
emersion: how do you turn that off/on ? I was looking but couldn't find a Kconfig that looked relevant
<emersion>
oh, wait
<emersion>
do you mean import/export a DMA-BUF, as in CAP_PRIME?
<emersion>
or do you mean import/export a sync_file from/to a DMA-BUF, as in jason's patch which didn't land?
<emersion>
(yet)
aravind has quit [Ping timeout: 480 seconds]
flto_ has quit []
<javierm>
emersion: I don't know :) just was wondering if the new sysfs entry would be /sys/kernel/dmabuf/has_sync_file_import_export or /sys/kernel/dmabuf/$driver/has_sync_file_import_export
flto has joined #dri-devel
<emersion>
ah, no, it would be global, nothing driver-speciifc
<javierm>
emersion: ah, gotcha. So then the only way you could do this was calling DMA_BUF_IOCTL_IMPORT_SYNC_FILE and checking if dma_buf_ioctl() failed with -ENOTTY
<emersion>
yup
<javierm>
and that's why you said that needed to allocate a dma-buf to do that
<javierm>
I understand the problem now, thanks for the additional context
<javierm>
emersion, danvet: I wonder then if instead of has_sync_file_import_export there should be a /sys/kernel/dmabuf/ioctls/{import,export}_sync_file and also for the other ioctls
<emersion>
it might not be just ioctls
<javierm>
that way when in the future anothre ioctl is added, we can nicely put it there instead of having random sysfs entries laying around in the root of the dir
<emersion>
/caps/… maybe
<javierm>
emersion: right, caps make sense
<javierm>
what I tried to say is to make it more forward looking
<emersion>
hm, interesting, vkGetFenceFdKHR followed by vkWaitForFences on the same VkFence makes vkWaitForFences block forever…
<emersion>
removing vkGetFenceFdKHR fixes it
<emersion>
bnieuwenhuizen: any idea what might happen here?
<emersion>
oh
<emersion>
it seems like there's some unclear wording in the spec about export resetting the fence
<emersion>
… great
JohnnyonFlame has joined #dri-devel
alyssa has joined #dri-devel
ppascher has joined #dri-devel
<alyssa>
kernel etiquette question-- I posted a series, all patches have r-b's from the respective maintainers, and I have drm-misc push access
<alyssa>
how long do I let it sit (waiting for additional detractors who were cc'd but have not yet read it) before pushing?
<emersion>
i'd say ~1 week?
<javierm>
alyssa: my understanding is that if is for a driver, you shouldn't really wait that much if already have r-b
<javierm>
alyssa: if also touches core changes or other subsystems, then maybe a week or two as emersion said
<javierm>
*core code
<alyssa>
emersion: OK. FWIW, it's v2 of the series, v1 was sent months ago, and not much changed (other than addressing v1 review comments)
<danvet>
yeah for core code 1-2 weeks fo soaking is nice
<danvet>
for core code that has seen lots of discussion in the past explicit pings are better
<alyssa>
javierm: OK.. (This is driver + dt-bindings for that driver)
<danvet>
for driver just push when it's reviewed by the folks who care
<javierm>
alyssa: then I would just push it :)
<danvet>
alyssa, dt needs r-b from robher or some other dt maintainer
<danvet>
that one is a bit special
<alyssa>
danvet: yeah, rob r-b'd
<danvet>
then push
<alyssa>
Oki. Time to discover how to vim.
<alyssa>
*dim
<alyssa>
i know how to vim
<alyssa>
$ vim drm-misc/
<alyssa>
:wq!
<alyssa>
did it work? is it pushed?
<alyssa>
:-p
khfeng has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
<emersion>
hm does polling a sync_file work?
Danct12 has quit [Remote host closed the connection]
saurabhg has joined #dri-devel
<robher>
we're going turn alyssa into a kernel dev.
<daniels>
emersion: yeah, GetFenceFD 'consumes' the temporary state in the same manner as a wait itself does
<emersion>
that's not very convenient when you don't know whether you need to vkWait or whether importing the sync_file into a DMA-BUF will work
<emersion>
is there a way to duplicate a VkFence?
<emersion>
i guess i should just type this kernel patch
<HdkR>
uhu, another kernel developer that I can throw FEX's terrible kernel problems at? :)
<daniels>
you could import the fd back into a fence if it didn't work?
<emersion>
yeah, i guess…
<emersion>
i've tried poll() on the sync_file but it causes validation layer errors
<emersion>
i'm not sure the import/export yo-yo will make validation layers happy
<alyssa>
robher: Is that a threat?
<HdkR>
Feels like a threat
<daniels>
emersion: er, how are the validation layers involved with the poll of an exported fd?
<emersion>
daniels: "Calling vkBeginCommandBuffer() on active VkCommandBuffer 0x6250000a7900[] before it has completed. You must check command buffer fence before this call. The Vulkan spec states: commandBuffer must not be in the recording or pending state"
<emersion>
hmm, but this might be unrelated i guess?
<emersion>
a bug made visible because i don't vkWaitForFences anymore?
<robher>
alyssa: Opportunity. It might be good to have something to fallback to when you run out of GPUs to RE. ;)
<alyssa>
robher: Ah. There's a long-standing threat to send me NPUs to RE ;)
flacks has quit [Quit: Quitter]
sdutt has joined #dri-devel
<alyssa>
Also, I probably have asked this but, how often does drm-misc-next get synced into linux-next?
saurabh_1 has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
Haaninjo has joined #dri-devel
<bnieuwenhuizen>
emersion: I'd argue that the validation layers are too strict there and not accounting for potential waiting on exported fences
<robher>
alyssa: It is pulled in every time linux-next is built, but not during the merge window as only fixes should be added.
<alyssa>
Right, okay
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
<jekstrand>
daniels: sysfs file in the dma-buf directory? You can do that?!?
<daniels>
dunno, try asking Vetter :P
<emersion>
yeah, the dir where the dmabuf entries are is in a subdir actually
<jekstrand>
danvet: ^^
<emersion>
/sys/kernel/dmabuf/ contains a singfe dir: buffers/
<emersion>
single*
<jekstrand>
Can I just open a file there and get a dma-buf?
<danvet>
no
<danvet>
that dir was added to dump some stats for android
<emersion>
it's just a sysfs API to get stats
saurabh_1 has quit [Ping timeout: 480 seconds]
<danvet>
except they don't like the locking overhead
<danvet>
but yeah the dir exists, so we could smash a caps/ in there and add stuff
<jekstrand>
emersion: if you're a compositor and you've already got a GL or Vulkan context, getting at a buffer handle to test shouldn't be hard.
<emersion>
jekstrand: i need to know at init time whether to enable explicit sync support or not
<emersion>
init time == before anything is getting allocated/rendered
<jekstrand>
emersion: :-/
<bnieuwenhuizen>
explicit sync support?
<emersion>
bnieuwenhuizen: the wayland protocol
<bnieuwenhuizen>
oh ok
<bnieuwenhuizen>
well, I'd say nothing prevent you from creating a dummy vk instance/device and trying it but don't know how that fits in your software arch
<jekstrand>
bnieuwenhuizen: Did you ack the dma-buf patches? I didn't see anything in my e-mail last night but haven't checked again yet this morning.
<robclark>
lumag_: I think msm-misc might need to pick that up? I don't have that file in my tree, looks like some other patch moved things around?
<emersion>
bnieuwenhuizen: it doesn't fit well
<jekstrand>
TBH, what I ended up doing for the Vulkan WSI patches wasn't great either
<emersion>
danvet: poll requiring v3.17 was for dmabuf or sync_file?
<danvet>
dmabuf
<lumag_>
robclark, linusw tried to pick up into the drm-misc, but then dim told him that the commit in 'Fixes' isn't an ancestor.
<robclark>
lumag_: looks like da68386d is the thing I don't have in my tree
<bnieuwenhuizen>
jekstrand: just did
<danvet>
emersion, sync_file had poll since forever
<emersion>
cool
<danvet>
but sync_file itself was only destaged in 4.7
<jekstrand>
bnieuwenhuizen: Thanks!
<jekstrand>
dj-death: ^^
<robclark>
lumag_, ask the submitter to rebase on msm-fixes? Or linusw to do a back merge from drm-next? I'm not sure what the preferred thing is
<lumag_>
Or change the 'Fixes' to point to 1e0f66420b13 ("drm/display: Introduce a DRM display-helper module")
<dj-death>
jekstrand: kernel patches?
<jekstrand>
dj-death: yes
<jekstrand>
dj-death: Or were you asking for where?
<lumag_>
robclark, ok, I've asked to change the fixes tag.
<robclark>
lumag_: yeah, that would work.. sgtm
<lumag_>
thanks
<robclark>
np
<dj-death>
jekstrand: I guess dri-devel, which I'm not subscribed to :(
<srslypascal>
since tbh I don't know jack shit about how both vesafb and grub's vbe and gfxterm modules work, I'm unsure if this is actually a bug in the kernel or in grub
<srslypascal>
(which results in me being unsure if reverting the kernel patch I've found through bisecting is actually the correct solution even though it makes the problem go away on my machine)
<srslypascal>
I've also tried rebuilding archlinux' grub package with 0001-reset-display_start-before-switching-mode.patch from here applied: https://savannah.gnu.org/bugs/?49814 though that didn't have any impact.
<srslypascal>
javierm perhaps? the kernel patch I've bisected the issue seems to have been written by you :)
nchery has joined #dri-devel
<javierm>
srslypascal: hmm, you mentioned in the arch bug that it can be reproduced with a VM too, were you able to get a kernel log using a serial console ?
<javierm>
srslypascal: ah, didn't see before. Thanks
<srslypascal>
though I'd reckon that the "archlinux_bug_74814_demo1.sh" might be more helpful to you since that one also contains the grub config involved, and there you can get the serial log as well (just gotta manually select the serial0 console in the qemu gui after you've selected the right entry in the grub boot menu)
<srslypascal>
btw, you can replace the "-device qxl-vga,…" parameter in the script/qemu command with "-vga qxl" if you want. at some point, I had assumed that the video ram parameters might have something to do with the bug and hence I've copied all those details from how libvirt invoked qemu on my machine, but it turns out that plain "-vga qxl" is sufficient to demonstrate the crash
<javierm>
srslypascal: yeah, I don't think the grub config is that relevant, you probably can reproduce it too with vga=$foo
<javierm>
it's just that when not using VBE, you just use vgacon but when making the kernel set a VGA mode, then fbcon + vesafb is used
<javierm>
srslypascal: this is yet again a struct fb_info lifetime issue :/
<srslypascal>
oh you're right, it also crashes with vga=792
<javierm>
srslypascal: oh, I think that know what happening
<javierm>
I should had thought that unregister_framebuffer(info) would freed info...
<javierm>
that is, it depends on whether .fb_destroy happens before .remove or not
<javierm>
I tested the patches leaving the fbdev opened since that was the case we tried to fix but then introduced another issue when destroy happens before removal...
<dj-death>
jekstrand: I'm looking at how this interact with dma-chain-fence, and I can't really see how we can export one point of the chain and import it on the dma_resv
<jekstrand>
dj-death: I don't think we have an ioctl for that on the syncobj side
<dj-death>
it's true that we're not supposed to do timelines with WSI yet :)
<dj-death>
but would be good to have for the future
<emersion>
oh, i got so excited about a patch that i double-acked it
<javierm>
emersion: haha
<javierm>
srslypascal: sorry for the inconvenience btw...
Duke`` has joined #dri-devel
<srslypascal>
javierm: nevermind, thanks for your work on the kernel. I'n the end, I'm basically just leeching off / consuming your work, so hard feeling about any bugs :D
<srslypascal>
*in the end
<jekstrand>
dj-death: Yeah, we probably want to add a version of syncobj import/export that takes a time point.
<emersion>
^ +1
<emersion>
you can export a binary drm_syncobj from a timeline, then turn it into a sync_file
<emersion>
to work around this
<daniels>
would be nice tho
<emersion>
yea
<jekstrand>
emersion: You can? I don't remember how.
<bnieuwenhuizen>
in general if we're taking shortcuts might be nice to have an ioctl to do it all on the raw syncobj without any export/import, that could then take timeline points as needed as well
<bnieuwenhuizen>
though I'm inclined to leave that until we see a perf issue
<emersion>
getting a sync_file is mostly for interop with other APIs
<emersion>
OpenGL, KMS, etc
<bnieuwenhuizen>
yeah for the compositor usecase you definitely want to keep the sync_file version, so I think if we only have one set of ioctls that is the one to have
<jekstrand>
emersion: Yeah, we should be able to do that in one ioctl.
<dj-death>
emersion: I don't think it works
<jekstrand>
TBH, I don't know why we did syncobj_transfer and didn't say a syncobj_transfer should just be an export+import.
<emersion>
dj-death: seemed to work when i tested, but maybe i missed something?
jstultz_ has quit []
<jekstrand>
Although... Now I'm thinking I should re-implement vk_sync_move with syncobj_transfer
jstultz has joined #dri-devel
<dj-death>
emersion: rereading the code, drm_syncobj_find_fence() seems to always get 0 when you go syncobj->syncfile
<emersion>
jekstrand: tbh i like the ability to do syncobj timeline ops without having to convert to sync_file
<dj-death>
emersion: so I think you won't get the fence you actually want
<bnieuwenhuizen>
jekstrand: the transfer ioctl is quite new, same timeframe as the timeline kernel stuff
<emersion>
dj-death: but should be fine since the suncobj i extract the sync_file from is binary?
<emersion>
syncobj*
<emersion>
thanks to that transfer ioctl
<danvet>
javierm, so another patch to review?
<dj-death>
I think the only difference is the dma-fence type really
<jekstrand>
bnieuwenhuizen: That's fine. If it's at the same time as the timeline stuff, that's also when we start needing vk_sync_move for the most part.
<jekstrand>
And we can have two different implementations and pick based on whether or not we have the ioctl.
<dj-death>
and because of dma_fence_chain_find_seqno(..., 0) it won't return the correct fence
<bnieuwenhuizen>
just giving the warning that you might need a fallback impl and hence more complexity
<dj-death>
it's fairly easy to write test to verify
<javierm>
danvet: I believe so, yes. Now srslypascal is testing to confirm that solves the issue
<javierm>
I should learn to avoid fbdev drivers and core at this point, it's really a mine field
<emersion>
dj-death: hm, i don't know the kernel logic enough to follow here
<srslypascal>
gonna take 1-2h until the kernel packages are built
<javierm>
srslypascal: Ok, please ping me once you have the result so I can post a proper patch to the list. And thanks gain!
zf_ is now known as zf
<srslypascal>
will do, thanks for the quick help :)
krushia_ has quit []
saurabh_1 has quit [Ping timeout: 480 seconds]
AndrewR has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<dj-death>
anybody knows to how to reply to a message-id from thunderbird? ;)
gawin has joined #dri-devel
Akari has joined #dri-devel
Anorelsan has joined #dri-devel
cheako has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
hch12907_ has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
technopo1rot has joined #dri-devel
technopoirot has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<kisak>
I expect that hardware acceleration with mesa on MacOS would require hardware/kernel access that Apple will never provide. They don't do third party video driver vendors.
iive has joined #dri-devel
<alyssa>
kisak: *coguhs*
<idr>
I mean... if a person can RE the hardware, RE'ing a kernel interface can't be that much worse.
<danvet>
I should go back to shitposting on twitter
<jekstrand>
Let me pull in that patch, re-build my tree, and make my Mesa patches use it.
<jekstrand>
It'll make things a bit easier for sure.
agd5f has quit [Ping timeout: 480 seconds]
<srslypascal>
javierm: sorry, the compile run will take a bit longer than I anticipated. usually, I use MAKEFLAGS+=" -j16" in my custom PKGBUILD, but for this, used the "original" PKGBUILD from the linux-hardened maintainer, which runs single-threaded :/
<emersion>
samples/kobject/kobject-example.c was also quite helpful
<srslypascal>
but I'm optimistic that it will be finished within an hour
<javierm>
srslypascal: no worries, I can post the patch anyways and Cc you so you could report back in the list
<javierm>
srslypascal: what's your email address?
<srslypascal>
$listid@hardfalcon.net
<javierm>
srslypascal: Ok, and real name Pascal Ernster right? I'll add you as Reported-by
<danvet>
emersion, should be v5.20
<srslypascal>
yes, the name is correct
<javierm>
srslypascal: Ok, thanks
<gawin>
does es 2.0 require support for loops which you cannot unroll? I remember reading something like "it should be known at compile time"
<srslypascal>
is that a list where I can reply with a normal thunderbird setup, or is it one of those things where basically the only way is to have git send emails?
<javierm>
srslypascal: you can responder with normal thunderbird setup
<danvet>
emersion, also maybe cc gregkh, iirc there's tons of macros and stuff to simplify boilerplate in sysfs attribute groups
<srslypascal>
thx :)
<danvet>
but maybe you're at the max already
<emersion>
ack
Danct12 has joined #dri-devel
<danvet>
I'm thinking we can't be the only ones with a RO sysfs file with a constant "1\n" output :-)
<emersion>
ahah
<javierm>
srslypascal: $listid as in dri-devel@hardfalcon.net right ?
<javierm>
just want to be sure I understood you correctly :)
alyssa has left #dri-devel [#dri-devel]
<srslypascal>
it's a catchall address, though if you wait 20-30 minutes, I can give you actual test results
<jekstrand>
danvet: Should we test the sysfs at all?
<srslypascal>
(from a bare metal machine, not just a VM)
<danvet>
jekstrand, you mean in igt?
<jekstrand>
danvet: Yeah
<danvet>
I guess you could use it in the igt_require and make everything else fail
<danvet>
but that's about it imo
<srslypascal>
the packages are getting compressed I type these characters
<danvet>
if you want to switch mesa over to using it and merge it all together
<jekstrand>
emersion: Uh... I'm not seeing /sys/kernel/dmabuf/caps
<srslypascal>
*as I type
<javierm>
srslypascal: it's OK, it would be useful to also have your answer to the patch with a Tested-by: Pascal Ernster <dri-devel@hardfalcon.net> if it works
<srslypascal>
ok
<emersion>
hmm, not sure what to say, i saw it in my testing :S
<jekstrand>
emersion: NVM. I failed at installing kernels.
<emersion>
phew :P
<emersion>
i also tested without CONFIG_DMABUF_SYSFS_STATS or whatever it's called
<jekstrand>
:+1:
* Lyude
finally cleaning up atomic-only MST helpers and getting ready for submitting them :)
bluebugs has quit [Remote host closed the connection]
bluebugs has joined #dri-devel
<jekstrand>
emersion: Ok, got the right build now. :)
<emersion>
noice
<srslypascal>
javierm: your patch solves the issue at least in the VM, and within the next 5-10 minutes I'll know if it also solves the issue on my bare metal server :)
<javierm>
srslypascal: awesome, thanks a lot for all the assitance
<javierm>
srslypascal: patch posted, feel free to answer there with your results
<srslypascal>
make that 2 minutes for the bare metal server
<srslypascal>
might take a bit till I can answer the mail as my mailserver is hosted on that bare metal server :D
<javierm>
srslypascal: LOL
<srslypascal>
problem solved, your patch also fixes the issue on my bare metal server :)
<javierm>
srslypascal: great
<srslypascal>
I'll answer the mail as soon as it has been delivered to my MTA ^^
<javierm>
srslypascal: sure, I need a Reviewed-by anyways before being able to push so there's no rush
<srslypascal>
should I use any special flag/line, or just normal human-readable text?
<javierm>
srslypascal: just human readable text but add a Tested-by: Pascal Ernster <dri-devel@hardfalcon.net> in one of the lines
<javierm>
since that way it will be picked by patchwork
<dj-death>
jekstrand: sorry if it's not in the thread :)
<jekstrand>
dj-death: No worries.
Duke`` has quit [Ping timeout: 480 seconds]
agd5f_ has quit []
technopo1rot has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
mvlad has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
Daaanct12 has joined #dri-devel
Daaanct12 is now known as Danct12
Daanct12 has quit [Ping timeout: 480 seconds]
<jekstrand>
emersion: I just pushed a new patch to !4037 which switches to the new cap.
<jekstrand>
emersion: I'll review your patch after a bit. Got an errand to run first.
danvet has quit [Ping timeout: 480 seconds]
<emersion>
cool!
colemickens has joined #dri-devel
icecream95 has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
mclasen_ has joined #dri-devel
danvet has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
<javierm>
dj-death: interesting, in that thread they said that worked if you enclosed the message-id with <>
mclasen_ has quit [Ping timeout: 480 seconds]
<graphitemaster>
I cannot find a good answer for this, does imageSize() in GLSL just compile down to some hidden uniform? Is it more or less expensive than just passing your own uniform?
<graphitemaster>
I'd assume that some hardware just knows the texture size in the sampler or something and doesn't need additional storage to marshal this
<graphitemaster>
ditto for textureSize
MajorBiscuit has joined #dri-devel
sdutt has quit []
rasterman has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.4]
<dj-death>
graphitemaster: on intel we send a message to the HW (not sure it's the actual sampler responding)
<graphitemaster>
Considering that an image and texture is just an integer uniform, I'd just artificially extend it to a ivec3 and store w/h in yz
<dj-death>
graphitemaster: you could do it by reading the bits in the descriptor, which is at an offset from some other base address
<dj-death>
ah... yeah I guess
frankbinns has quit [Remote host closed the connection]
<jekstrand>
graphitemaster: Depends on your hardware. :)
<jekstrand>
graphitemaster: Lots of hardware has messages you can send to the sampler to get it. Other hardware requires you to pass it in or go read the image descriptor and decode it manually in the shader.
ngcortes has joined #dri-devel
<jekstrand>
graphitemaster: Generally, I would assume it's fast enough that it's not worth you doing gymnastics to avoid it.
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
danvet has quit [Ping timeout: 480 seconds]
<HdkR>
If imageSize is your bottleneck, someone needs to sternly look at that driver stack :P
<jekstrand>
^^
apinheiro has quit [Quit: Leaving]
technopoirot has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
ybogdano has joined #dri-devel
heat has joined #dri-devel
pcercuei has quit [Quit: dodo]
rkanwal1 has joined #dri-devel
rkanwal has quit [Read error: Connection reset by peer]
iive has quit []
mclasen has joined #dri-devel
mclasen has quit [Remote host closed the connection]
<graphitemaster>
Alright, I'll stop passing around my own image size uniforms
<graphitemaster>
There used to be a day that doing this was expensive I want you to know
<graphitemaster>
Or well, there used to be a day back in the day when it did not exist and using it on some drivers just spit out 0 so I avoided it and then my brain just defaults to the idea that avoiding something means it's slow when really it could mean it was just broken as hell
<HdkR>
It was broken on some of the first Adreno ES 3.0 drivers sadly. Took a couple years for it to stop being broken.