ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Haaninjo has quit [Quit: Ex-Chat]
LeviYun has joined #dri-devel
epoch101 has joined #dri-devel
RAOF has quit [Remote host closed the connection]
RAOF has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
alethkit has quit [Ping timeout: 480 seconds]
kennylevinsen has quit [Ping timeout: 480 seconds]
kennylevinsen has joined #dri-devel
alethkit has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
simon-perretta-img_ has joined #dri-devel
LeviYun has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
ellyq_ has joined #dri-devel
yyds has joined #dri-devel
ellyq has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
alane has quit []
alane has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
ellyq_ has quit [Ping timeout: 480 seconds]
adavy has quit [Remote host closed the connection]
adavy has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
moony has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<demarchi>
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c is left unmerged
<demarchi>
Merging drm/drm-next... dim:
<demarchi>
dim: FAILURE: Could not merge drm/drm-next
<demarchi>
anyone looking at that?
LeviYun has joined #dri-devel
<airlied>
demarchi: yup
<airlied>
just in the middle of it
<airlied>
demarchi: fixed
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
epoch101 has quit []
LeviYun has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
lemonzest has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<demarchi>
airlied: thanks
kzd has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
Duke`` has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
simon-perretta-img has joined #dri-devel
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
yyds_ has quit [Remote host closed the connection]
yyds has joined #dri-devel
moony has joined #dri-devel
Duke`` has quit []
spkry has joined #dri-devel
spkry has quit []
tzimmermann has joined #dri-devel
Duke`` has joined #dri-devel
checkfoc_us has quit []
checkfoc_us has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
mceier is now known as Guest3134
Mangix has quit [Read error: Connection reset by peer]
mceier has joined #dri-devel
Mangix has joined #dri-devel
Guest3134 has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
itoral has joined #dri-devel
fab has quit [Quit: fab]
yyds has joined #dri-devel
LeviYun has joined #dri-devel
coldfeet has joined #dri-devel
i-garrison has quit []
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
jsa has joined #dri-devel
i-garrison has joined #dri-devel
rasterman has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
LeviYun has joined #dri-devel
vliaskov has joined #dri-devel
sima has joined #dri-devel
fab has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<tzimmermann>
sima, airlied, hi. could i have the latest -rc in drm-next, so th ti can backmerge into drm-misc-next? specifically, i want commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary")
<sima>
I'll look into it, need to get some breakfast first though or the brain is not going to be on board with thinking :-)
<tzimmermann>
sima, thanks a lot. no hurry
<tzimmermann>
:)
f11f12 has joined #dri-devel
apinheiro has joined #dri-devel
avolmat has joined #dri-devel
checkfoc_us9 has joined #dri-devel
checkfoc_us has quit [Read error: Connection reset by peer]
coldfeet has joined #dri-devel
kts has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
<sima>
tzimmermann, airlied backmerge pushed
<tzimmermann>
thank you
lynxeye has joined #dri-devel
Company has joined #dri-devel
Lucretia has joined #dri-devel
ManMower has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #dri-devel
ManMower has joined #dri-devel
jsa1 has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
jkrzyszt has joined #dri-devel
simon-perretta-img_ has quit []
simon-perretta-img_ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
itoral has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
itoral has joined #dri-devel
jmnemoni has quit [Remote host closed the connection]
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #dri-devel
pcercuei has joined #dri-devel
jsa has joined #dri-devel
kts has joined #dri-devel
yyds has quit [Remote host closed the connection]
jmnemoni has joined #dri-devel
jmnemoni has quit [Remote host closed the connection]
jmnemoniqueueanon has joined #dri-devel
mahkoh has joined #dri-devel
<mahkoh>
Hi. Sometimes when use DRM_IOCTL_MODE_ATOMIC to attach a new framebuffer or move the cursor plane, I miss the next page flip even though it is still >1.5ms away at the time the ioctl returns (measured by continuously requesting DRM_EVENT_CRTC_SEQUENCE). Usually this happens during low activity. Is this due to lower power states? Even so, 1.5ms sounds like it should be more than
<mahkoh>
enough. Is there any way to debug this? On AMDGPU.
<mahkoh>
Forgot to say: Implicit sync is disabled for these commits by explicitly attaching a signaled sync file.
yuq825 has left #dri-devel [#dri-devel]
jsa has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
heat has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
gtpfs[m] has joined #dri-devel
gtpfs[m] has left #dri-devel [#dri-devel]
nerdopolis has joined #dri-devel
kasper93 has quit [Remote host closed the connection]
<emersion>
if we return it in vkQueuePresentKHR, maybe it gives more time for the app to recreate the swapchain resources
<emersion>
not sure if there are any other differences
rgallaispou has joined #dri-devel
<emersion>
maybe some apps forget to handle SUBOPTIMAL for one of these two functions
<llyyr>
yeah I'm not sure if it's intentional or not, my first thought is we should return it in both but x11 only returns suboptimal on vkQueuePresentKHR while wayland only returns suboptimal on vkAcquireNextImageKHR
mbrost has joined #dri-devel
<Company>
it's a bit meh if you return it in present
<Company>
"oh, all you've just drawn is wrong, better luck next time!"
<llyyr>
Some apps may only handle suboptimal for one of these functions though, like dxvk did
<Company>
does X never return SUBOPTIMAL in Acquire(), even if the previous present returned it?
<llyyr>
oh it does, sorry
<Company>
good, then GTK is only somewhat broken in that sense
<llyyr>
I guess wayland should also return suboptimal in QueuePresent then
<llyyr>
I don't think it's intended that return codes can flip flop between suboptimal and success
crabbedhaloablut has quit []
<Company>
"The result codes VK_ERROR_OUT_OF_DATE_KHR and VK_SUBOPTIMAL_KHR have the same meaning when returned by vkQueuePresentKHR as they do when returned by vkAcquireNextImageKHR."
<Company>
the spec seems to agree
crabbedhaloablut has joined #dri-devel
Duke`` has joined #dri-devel
<llyyr>
should this be part of !31122 or its own MR?
mbrost_ has joined #dri-devel
jmnemoniqueueanon has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
<emersion>
my reading is that it's up to the driver whether to return in Present or Acquire() or both
<llyyr>
hmm
<emersion>
on some platforms/drivers it may be easier to return it from one or the other
<emersion>
but i'd be very happy to be proven wrong
<emersion>
zmike, do you know? ^
epoch101 has quit []
tjmercier has quit [Quit: Leaving]
<zmike>
it does not have to return in present
<llyyr>
but should it?
<zmike>
I deleted suboptimal from present on x11 a while ago for performance reasons
<zmike>
K900: I forgot to click submit, but you have my blessing
<K900>
I think you might be the most knowledgeable person on GBM/DRI/Mesa internal interactions at this point
<zmike>
next step would be moving repos
<K900>
Why the fuck is everyone so excited about gbm moving repos lol
<K900>
I was like
<K900>
100% sure no one but us gave a shit
<K900>
(us as in NixOS)
<zmike>
because then there's less code in mesa and less complexity
<K900>
Oh I see you just don't want to touch it :P
<K900>
Valid, honestly
<zmike>
yes
<emersion>
i'm a bit meh on the split repo thing
<emersion>
more overhead to manage releases etc
<zmike>
the code won't change so there won't be releases
<emersion>
mesa no longer in sync with the other repo so API changes are annoying
<K900>
I mean the actual splittable part of libgbm has barely changed, like, ever
<emersion>
well
<emersion>
we might want to add allocation constraints at some point
<K900>
But yes if you ever wanted to add more API surface then it'll be harder
<K900>
Though you could always just do GBM first and then Mesa
<emersion>
i've occasionally added new API to GBM
<K900>
Because GBM will have to have backcompat
<K900>
* have backcompat anyway
<emersion>
like, get_fd_for_plane()
<emersion>
iirc minigbm wanted to add another getter as well
<zmike>
minigbm should probably just die
<emersion>
yeah, i mean, it's just more work
<emersion>
also i added create_bo_with_modifiers2()
anujp has quit [Ping timeout: 480 seconds]
<K900>
I assume if gbm gets excised from Mesa minigbm would just be unnecessary?
<DemiMarie>
I thought minigbm had a bunch of hardware-specific information
<emersion>
they have an extended API, and their impl is different
<emersion>
ideally it would be a gbm backend…
<daniels>
^
<DemiMarie>
Is there any solution for desktop platforms to the problems that really do need an omniscient allocator?
anujp has joined #dri-devel
<daniels>
... an omniscient allocator?
<DemiMarie>
One that knows about every device on the system
<DavidHeidelberg>
Btw. are people happy with merging gfxstream? I see lot of open discussion and Gurchetan Singh assigned the MR to Marge bot already
<DavidHeidelberg>
I would expect some core (and active) Mesa developer will be merging it, when majority is happy with it
<Sachiel>
tractor based development
<zmike>
huh I didn't expect him to be able to assign
<zmike>
I was planning to give ajax a week or so
<zmike>
in case he wanted to test again
<zmike>
but yeah I was planning to ack
<DavidHeidelberg>
yeah, I don't like him pushing it that agressively
<DavidHeidelberg>
I mean, I sometimes push some small stuff with one A-b/R-b, but that's incremental improvements, not a huge pile of code, where is not yet consensus about merging it
<zmike>
I'm just surprised he had assign permissions
<DavidHeidelberg>
also so far lygstate gave A-b, one Blackberry guy gave R-b (and second BB employee said how wonderful is it). I mean, if it brings something useful for Mesa, why not, but I'm not much convinced yet. Also no CI, no plan to sponsor CI, plan to test it time to time....
<DavidHeidelberg>
I would like to see vendors shipping Mesa on Android and contributing as it has value for Linux part of drivers too.. just not sure how gfxstream fits there
uriah has joined #dri-devel
<zmike>
I think it will show value in the coming months
<zmike>
they'll sponsor CI once it's merged, from what I gather
<zmike>
but there was also pushback in the MR against them integrating CI
<Kayden>
oh wow, yeah, that's a huge pile of new project
<zmike>
so ofc they're not going to be posting about CI plans
<Kayden>
and not even the same license as the rest of the project
<karolherbst>
what license does it have?
<DavidHeidelberg>
zmike: btw. for the CI pushback, that make sense. If someone drops code and then forces devs working on other stuff fight with it without helps, that's bad
<zmike>
yeah
<zmike>
but I don't think that's a blocker
<karolherbst>
mhh apache apparently
<Kayden>
it's apache 2, which isn't necessarily bad, just odd to be different
<DavidHeidelberg>
if they don't drop the code, but start "continuously" working on it within Mesa and work as part of FOSS project, then I personally (and others) welcome CI :D
<karolherbst>
why are they checking in generated files though?
<zmike>
we've got another branch point next month, so we could also wait until after that if we're hesitant
<DavidHeidelberg>
and if it'll bring some useful stuff outside of mostly proprietary Android
<karolherbst>
can't they just.. generate it in the build?
<zmike>
and if they aren't good citizens we can yeet before the release
<llyyr>
karolherbst: "About 112 kLoC added. 92kLoC is autogenerated code, which we plan to generate at build time eventually. However, it's interesting technical problem on it's own and this MR doesn't endeavor to solve the "build-time VK autogen" problem right now."
<karolherbst>
uhh...
<karolherbst>
okay?
<llyyr>
a lot of code
<karolherbst>
sure, but also a pain to review if the autogen changes significantly, I'd rather just see the generator tbh
<karolherbst>
at least maybe it would be helpful to know what kind of generator it is
<llyyr>
I'm just a regular user so no opinions, just copypasted what they had to say about the autogen code
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
aljazmc has joined #dri-devel
luc has quit [Quit: Connection closed for inactivity]
<DemiMarie>
Why would it be hard to generate at build time? Is the generator closed source?
Company has quit [Quit: Leaving]
fab has quit [Quit: fab]
<HdkR>
Google-isms, it's probably tied in to some random bazel build system
<HdkR>
Alternatively, it requires building all of Android to get the build artifacts
<airlied>
yeah I'd say the same
mbrost has quit [Remote host closed the connection]
epoch101 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
kugel_ has quit []
docmax_ has quit []
kugel has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
bbrezill1 has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
<DemiMarie>
I noticed that the bug reporting instructions for at lest some drivers ask the user to check on drm-tip. This is often not an option for a variety of reasons, such as not knowing how to compile kernels or not being willing to run a development snapshot on a production machine. What should these users do?
<DemiMarie>
To clarify, I consider "used for serious work and must be reliable" to be "production" for client systems.
aljazmc has quit []
<DemiMarie>
Should such users report bugs to their distributions instead?