ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Leopold has quit [Ping timeout: 480 seconds]
<Company>
alyssa: the longer answer is that we have to if we want to have multiple libraries that all do stuff with GL and want to interoperate (Wayland, GTK, GStreamer, ...)
<Company>
and then we either use GL and share texture ids, which is what we do now
<Company>
or we use the lower layer platform API (EGL, GLX, ...) but that requires custom code for each platform because not everyone does EGL
<zmike>
just use vk
<Company>
that also doesn't work (yet) because it's not supported everywhere
<Company>
I also have no idea if vk is a great API for sharing things
<Company>
like, do I need to share instances? devices? physical devices? queues? Or can any library create their own and then sharing images just works?
<jenatali>
zmike: Do you actually get any benefit from using those difficulty labels on your MRs?
<jenatali>
Wondering if my 2-liner needs a difficulty: easy label
rosefromthedead has quit [Remote host closed the connection]
<zmike>
jenatali: the idea is that it's for reviewers; if you see "easy" on an MR then that should indicate that either someone who doesn't know X driver could review it or that someone who does could review it at a glance
<zmike>
I use "hard" if it's something especially opaque
<jenatali>
I get the idea. Just wondering if you've ever heard that it helps
<zmike>
dunno, but airlied always reviews the ones I've tagged "easy" first, so I have to assume it does something :P
<jenatali>
Good enough for me :P
danilo has joined #dri-devel
<zmike>
and then of course there's the gfxstrand sweet spot of easy / zink / spirv
<zmike>
so yeah, I think it's got some subtle benefit
dakr has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
nchery has quit [Quit: Leaving]
<alyssa>
zmike: i have faith in those reviews
shsharma__ has joined #dri-devel
shsharma_ has quit [Ping timeout: 480 seconds]
<Lynne>
Company: vulkan is great for sharing things!
<Lynne>
just not if the things they're sharing are queues
<Lynne>
because for some idiotic reason queue objects are externally synchronized
<Lynne>
so all users have to share a mutex as well just to submit
<jenatali>
Lynne: Thank you for justifying our decision to make D3D12 queues internally synchronized
<Lynne>
oh, it gets better
<Lynne>
you have to use mutexes
<DavidHeidelberg[m]>
Brace yourself. Debian bookworm based CI coming.
<Lynne>
which is great, because mutexes are portable and available on all systems always
<Lynne>
which of course, they are not, so in ffmpeg we resorted to exposing lock_queue/unlock_queue functions
co1umbarius has joined #dri-devel
<airlied>
Lynne: there are platforms with vulkan but no mutexes?
ngcortes has quit [Ping timeout: 480 seconds]
<Lynne>
os/2? I think?
columbarius has quit [Ping timeout: 480 seconds]
<airlied>
no vulkan there :-)
<Lynne>
windows
<Lynne>
with msvc
<Company>
all I want to do is potably share GPU memory - why does that have to be so hard?
<Lynne>
there probably is an os/2 version of vulkan, it's still a very popular embedded OS in china
<Lynne>
(ffmpeg did support os/2 as of a few years ago, we removed support for it, but some chinese dev still very regularly maintains a fork)
<airlied>
we have windows mutex abstractions in mesa I'm pretty sure
<Company>
vkMutex when?
<Lynne>
yeah, we do as well, but we don't expose mutexes via the API, because of .dll interactions
<Lynne>
vkFence would've worked too instead of a mutex, but of course, the fence object is also externally synchronized
<Lynne>
when submitting command buffers
<Lynne>
isn't it great, a synchronization object that is externally synchronized
<Lynne>
just think about all the delicious driver optimizations possible! non-blocking user submissions means a constant stream of command buffers, all for the driver to put into a nice internal threaded submit queue, never starved or blocking
ngcortes has joined #dri-devel
schaeffer has joined #dri-devel
<jenatali>
Lynne: MSVC absolutely has mutexes
<schaeffer>
hello - not sure if this is the right channel to ask in but i was taking a look at a merge request to get adreno a690 support in mesa (i'm on a thinkpad x13s) and while i was able to build and test out mesa, it appears the loader is using the swrast driver instead of freedreno. where can i look to find more information about what might be going on? i'm completely new to this so any
<jenatali>
Well I dunno about the C11 one specifically, but it does have a C++11 one plus platform-native
<schaeffer>
alright, that looked a lot less wordy when i was typing it
<airlied>
schaeffer: you have a working kernel module?
khfeng has quit [Ping timeout: 480 seconds]
<schaeffer>
airlied: module for what specifically? this all is totally new to me and so i was mostly just poking at LD_LIBRARY_PATH per the docs
<schaeffer>
if there's documentation i can read that would be helpful i'm happy to read that
<airlied>
schaeffer: in order to use a gpu from mesa, you need to have something in the kernel working, it would be the msm module in that case
<airlied>
robclark or HdkR might know more about a690 requirements though
<HdkR>
schaeffer: Which kernel are you using? You need to have msm loaded `lsmod | grep "msm"`
<HdkR>
If you're booting with ACPI instead of device tree, then...don't do that.
<robclark>
there are kernel patches floating around for a690.. I think I am waiting still for a respin, but hopefully it makes it for v6.4.. in general #aarch64-laptops is a good resource
<robclark>
someone there should be able to point you at a kernel branch with all the various in-flight things including a690
<schaeffer>
right, i was messing around with kernel config options and wound up setting CONFIG_DRM_MSM=y instead of what i had before...let me rebuild the kernel and see what happens
<alyssa>
I heard X13s is a series laptop :o
<schaeffer>
robclark: got it, so i can't just use an off the shelf thing like what's floating around from linaro here?
<alyssa>
serious
<schaeffer>
"off the shelf" is doing some work there
<robclark>
you will need some extra patches.. linaro branch might have them, idk
<robclark>
alyssa: it can Crysis (Remastered, even) according to HdkR :-P
<schaeffer>
alyssa: it's been pretty decent so far, though i'd like to actually use more of the hardware lol
<HdkR>
A Crysis crisis
<schaeffer>
i'm willing to run a custom mesa and patched kernel to get this thing to work fwiw, mostly just looking to see where to begin
<schaeffer>
sounds like the MR will work assuming the kernel itself can support the a690, which requires said patches
<HdkR>
Indeed, the MR does work since I've tested it here
<alyssa>
:D
ngcortes has quit [Read error: Connection reset by peer]
<schaeffer>
ooh, we got another kernel to play with
<schaeffer>
i'll poke #aarch64-laptops and bounce back here once i kind of know what i'm doing
<schaeffer>
thanks to all of you for the helpful pointers
khfeng has joined #dri-devel
<robclark>
np
Danct12 has joined #dri-devel
<alyssa>
schaeffer: OOI, why'd you get an X13s (vs an x86 laptop or a macbook or a chromebook or something)?
* alyssa
is curious
<robclark>
alyssa: it is a pretty beefy step up from what is avail in chromebook form.. the 7c chromebooks are solid (I use on for daily driver for email/chat/docs type stuff).. but x13s has a lot more grunt.. compared to macbook it has more standard distro-friendly boot setup (ie. uefi/grub/etc) and no pesky recompile everything for 16k pages nonsense.. and the gl/vk driver situation is already pretty solid
<robclark>
if I had room for an extra laptop I'd buy one ;-)
<alyssa>
robclark: yeah, fair enough. what about x86 stuff though?
<schaeffer>
alyssa: all of what robclark said, but also for fun
<robclark>
what is this x86 nonsense ;-)
<alyssa>
I mean if I wasn't doing mac stuff I'd totally snag one myself don't get me wrong :~p
<alyssa>
but what is this x86 nonsense, exactly :~p
columbarius has joined #dri-devel
<schaeffer>
one motivating factor actually was i do a lot of stuff on a pi k8s cluster/homelab thing, and building images using qemu was getting grating
co1umbarius has quit [Ping timeout: 480 seconds]
<schaeffer>
i also learn by causing problems for myself, like buying an ARM laptop and trying to get the GPU running
<alyssa>
schaeffer: fwiw re macbook, asahi is a standard uefi (via u-boot) + grub/whatever setup
<alyssa>
er, robclark
<alyssa>
and the asahi installer takes care of that, so if the kernel support were there, in theory the standard distros should work
<alyssa>
^mainline
<schaeffer>
oh yeah, re: an M1/M2, getting this one was just more for fun
<robclark>
not knocking u-boot uefi (I've contributed to it) but the qc laptops are real uefi
<alyssa>
as for pages... the official recommendation is and will continue to be 16k pages but there's been a 4k page patch floating around since forever and at some point marcan will lose the staring contest with HdkR and merge it :-p
<HdkR>
Obviously we need to casually glare at the video game industry
<robclark>
also... qcom is (at least indirectly via linaro) working on upstream support for these things.. vs apple..
<schaeffer>
i will say on that note there are also lenovo employees that are actively engaging with this publicly too
<robclark>
I mean, if I were in apple's shoes I'd probably make the same decisions.. they do what is right for _their_ ecosystem..
<robclark>
that too, ofc
<schaeffer>
but i don't have very strong opinions here, just a computer i want to go fast
<alyssa>
schaeffer: oh, nice, I didn't realize that there was official support happening, that's awesome
<alyssa>
now I kinda want one
<alyssa>
wait crap I already work on too many drivers I don't need to add turnip to the list :p
<alyssa>
or do I
* alyssa
laughs evilly
<robclark>
alyssa: come to the dark side.. we have dragons.. and cookies :-P
<HdkR>
ginger snap cookies?
<robclark>
yup
<robclark>
:-P
Zopolis4 has joined #dri-devel
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
khfeng has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest8007
srslypascal has joined #dri-devel
kawagucci has joined #dri-devel
Guest8007 has quit [Ping timeout: 480 seconds]
kawagucci has left #dri-devel [#dri-devel]
<steev>
i want an alyssa signed thinkpad :(
bmodem has joined #dri-devel
chipxxx has joined #dri-devel
chipxxx has joined #dri-devel
chip_x has joined #dri-devel
Fijxu has quit []
Fijxu has joined #dri-devel
kawagucci has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
chip_x has quit [Ping timeout: 480 seconds]
chip_x has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
chipxxx has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
Guest7983 is now known as nchery
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
Zopolis4 has quit []
kawagucci has quit []
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
JohnnyonF has joined #dri-devel
danvet has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
Fijxu has quit []
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
dviola has joined #dri-devel
Shibe has quit [Ping timeout: 480 seconds]
Shibe has joined #dri-devel
junaid has joined #dri-devel
kts has joined #dri-devel
alanc has quit [Remote host closed the connection]
junaid has quit [Quit: leaving]
alanc has joined #dri-devel
pochu has joined #dri-devel
fab has quit [Quit: fab]
yuq825 has joined #dri-devel
junaid has joined #dri-devel
Company has quit [Quit: Leaving]
MajorBiscuit has joined #dri-devel
junaid has quit [Remote host closed the connection]
mvlad has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tursulin has joined #dri-devel
srslypascal is now known as Guest8024
srslypascal has joined #dri-devel
tzimmermann has joined #dri-devel
Guest8024 has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
zzoon has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
junaid has joined #dri-devel
jkrzyszt has joined #dri-devel
pcercuei has joined #dri-devel
lynxeye has joined #dri-devel
junaid has quit [Remote host closed the connection]
SolarAquarion has quit []
agd5f_ has joined #dri-devel
Shibe has quit [Ping timeout: 480 seconds]
Shibe has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
Shibe has quit [Ping timeout: 480 seconds]
Shibe has joined #dri-devel
SolarAquarion has joined #dri-devel
bluetail has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<marex>
hey, I was curious, is the effort to upstream the powervr rogue GPU support effectively dead now ?
MajorBiscuit has joined #dri-devel
<marex>
it seems the activity just stopped when the userspace component landed in mesa, but there is no kernel driver to match it, and no matching firmware for but a few very specific SoCs
srslypascal has joined #dri-devel
Ahuj has joined #dri-devel
ceoltb^ has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
jdavies has joined #dri-devel
agd5f has joined #dri-devel
jdavies is now known as Guest8033
agd5f_ has quit [Ping timeout: 480 seconds]
Guest8033 has quit [Ping timeout: 480 seconds]
dtmrzgl has quit []
MajorBiscuit has joined #dri-devel
rasterman has joined #dri-devel
jdavies_ has joined #dri-devel
jdavies_ has quit [Remote host closed the connection]
bluetail has joined #dri-devel
bluetail has quit [Remote host closed the connection]
bluetail has joined #dri-devel
bluetail has quit [Remote host closed the connection]
bluetail has joined #dri-devel
srslypascal is now known as Guest8036
srslypascal has joined #dri-devel
dtmrzgl has joined #dri-devel
Guest8036 has quit [Ping timeout: 480 seconds]
<lynxeye>
marex: Did your DSI clock negotiation proposal get anywhere? I'm currently looking at a regression from your tc358767 CLRSIPOCOUNT change. It seems we really need to calculate this parameter dynamically, but to do so properly we need to know the actual HS clock chosen by the DSI host.
camus has quit [Remote host closed the connection]
<marex>
lynxeye: nope, both attempts crashed at mripard
<marex>
lynxeye: dang
<marex>
lynxeye: I also feel like the DSIM host should calculate the PHYTIMING_HS_ZERO and co dynamically
<marex>
lynxeye: NXP downstream crud has some sort of table for it, but it could be calculated, and with the static settings we have a problem there
<marex>
lynxeye: I expect when the DSIM driver finally lands, that and the clock rate negotiation would be the two improvements to do up next
enunes[m] has quit []
enunes[m] has joined #dri-devel
camus has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
fab has quit [Quit: fab]
<lynxeye>
marex: Yea, Linux already has some helpers to help calculate the DPHY parameters dynamically, but that only helps for the host side. We really need a way to communicate the actually chosen HS rate to the DSI device side to allow proper PHY configuration there.
enunes[m] has quit [Quit: Reconnecting]
enunes[m] has joined #dri-devel
<marex>
lynxeye: yes we do
<marex>
lynxeye: and it should be extensible, in case we need to communicate more metadata
aknautiy_ has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
aknautiy has joined #dri-devel
<jenatali>
MrCooper: It didn't rebuild containers, it just built Mesa because you touched CI config, which builds everything
aknautiy has quit [Read error: Connection reset by peer]
<marex>
lynxeye: do you plan to take another stab at the link rate negotiation ?
aknautiy has joined #dri-devel
pcercuei has quit [Quit: bbl]
camus has quit []
kxkamil has quit []
pochu has quit [Quit: leaving]
Danct12 has quit [Ping timeout: 480 seconds]
zehortigoza has quit [Remote host closed the connection]
MajorBiscuit has quit [Quit: WeeChat 3.6]
pcercuei has joined #dri-devel
junaid has joined #dri-devel
zehortigoza has joined #dri-devel
junaid has quit [Remote host closed the connection]
<lynxeye>
marex: I guess I need to, otherwise we'll just end up tweaking the phy parameters in the upstream drivers for our specific use-cases, breaking others in the process.
Haaninjo has joined #dri-devel
kzd has joined #dri-devel
<jenatali>
Maybe I'm missing something, but it looks like Vulkan drivers using vk_create_sorted_bindings can't match up binding flags after the sort. I see radv and tu using the binding field to index into the binding flags array, but that seems wrong...
yuq825 has left #dri-devel [#dri-devel]
<alyssa>
steev: alyssa signed thinkpads seem logistically complicated
<schaeffer>
alright, so i've ensured the msm module is built/seems to be working and have the a690 firmware loaded - mesa still seems to be only choosing the swrast driver though when i try to use my build to run glxinfo
<schaeffer>
not sure what causes it to use software rendering here though or how i can inspect what's going on
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
ngcortes has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
pcercuei has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
pcercuei has joined #dri-devel
jfalempe has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
mvlad has quit [Quit: Leaving]
<karolherbst>
cursed MR of the day: toggling context switched mmio registers via command buffers
shsharma__ is now known as shashanks
JohnnyonFlame has joined #dri-devel
Ahuj has joined #dri-devel
Zopolis4 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
mohamexiety has joined #dri-devel
mbrost has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: bbl]
fab has quit [Quit: fab]
nchery is now known as Guest8082
nchery has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
we have at least 3 independent alpha-to-coverage lowerings in tree
<alyssa>
should I add a fourth? :~p
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
JohnnyonF has joined #dri-devel
<alyssa>
brw_nir_lower_alpha_to_coverage -- has some Intel specific stuff that would need to be untangled
<alyssa>
dithers with some opaque formula that seems to work empirically but has no obvious justification
pa- has joined #dri-devel
<alyssa>
does up to MSAA 16x but could maybe be optimized if the driver doesn't go that high
<alyssa>
the NIR pass was added by Sagar Ghude but based on earlier code
<alyssa>
blaming further it was added in c8abe03f3b6 ("i965,iris,anv: Make alpha to coverage work with sample mask") by Danylo
<alyssa>
but the commit message credits it to curro
pa has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<schaeffer>
for anyone curious who isn't also in #aarch64-laptops, mesa is working for me on the x13s now :^)
<alyssa>
Woop
<schaeffer>
paradise was one ldconfig away
<alyssa>
is that a video game
<schaeffer>
kinda exciting really
<schaeffer>
well my computer uses a gpu, so in that sense maybe
<schaeffer>
now that this actually works i just need to start using this thing like an actual computer because i didn't actually think i'd get it working
cphealy has quit [Remote host closed the connection]
cphealy has joined #dri-devel
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
Fijxu has joined #dri-devel
<jenatali>
Sigh we were so close to having all the right subgroup ops in DXIL, but we're missing any inclusive scan ops, and we only have 2 exclusive scan ops, missing min/max/or/and/xor :(
<jenatali>
That's frustrating
ngcortes has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
<mohamexiety>
schaeffer: yoo, nice! actually, how's the aarch64 experience on linux in general?
<alyssa>
jenatali: happy lowering
<jenatali>
Yep
<jenatali>
Inclusive -> exclusive is fine, but oof implementing scans as loops :(
<alyssa>
bunch of hw does it ;d
ngcortes has joined #dri-devel
<jenatali>
Yeah maybe it's not that big of a deal then
<alyssa>
jenatali: Do us a favour and nir_lower_subgroups it?
<jenatali>
alyssa: I considered it but the cases for it are specific enough
<alyssa>
specific to dxil?
<jenatali>
I wasn't sure how to describe it in an options struct
<alyssa>
should_lower callback
<alyssa>
:P
<jenatali>
Yeah, I guess
<jenatali>
But even that isn't a bool. For inclusive, it's either lower to a loop, or lower to exclusive
<alyssa>
Aahh
<jenatali>
alyssa: I'm about to post the MR for it, the pass is trivially movable once we figure out how you want to describe the conditions
mbrost_ has joined #dri-devel
<alyssa>
jenatali: Fair enough
<alyssa>
I think I'm generally in favour of new NIR lowerings baking in drivers until there's a second user, so it's all good
<jenatali>
Sounds good
<alyssa>
what I really meant was, do us a favour and do it in NIR and not in DXIL
<jenatali>
Oh yeah for sure
<jenatali>
I thought about trying to write it in the backend and oof
mbrost has quit [Ping timeout: 480 seconds]
<jenatali>
!21996 if you were curious
<alyssa>
i'm always curious
<alyssa>
..it's kind of a problem actually
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<jenatali>
:P
<alyssa>
OOI you have an app actually using subgroups? that's neat :o
<alyssa>
..actualy, wait, what's the point of dozen anyway
<alyssa>
like i'm not complaining but isn't the whole point of writing a vulkan driver so you can layer d3d on top?
<alyssa>
:p
<zmike>
obviously it's for consuming ci cycles
<jenatali>
Trying to get DOOM Eternal up and running, fighting with so many iterations of "feature X isn't supported" on startup
<jenatali>
So I go to the spec for X and get the CTS for it passing, even if it means implementing stuff that no app is ever going to realistically use
<jenatali>
Well, WSL is one reason, as are some of our devices (like our ARM devices) which currently have no Vulkan driver
<alyssa>
zmike: oh, right no it's for zink
<ccr>
creating MRs similarly to playing a rhythm / dance game, with the goal of keeping CI under pressure?
<alyssa>
microsoft heard the right way to write a gl driver in $CURRENT_YEAR Is to write a vulkan driver
<alyssa>
so they're abandoning gallium/d3d12 in favour of zink-on-dozen-on-d3d12
<alyssa>
makes much more sense
<jenatali>
:P
<jenatali>
At this point it would probably be more feature-complete...
<jenatali>
Ah no Dozen doesn't do tess yet
<zmike>
but jenatali think of the P E R F
<jenatali>
And neither would gallium/d3d12 except that it's required for 4.0
<jenatali>
The number of bugs this has caught in our software rasterizer is insane though
<jenatali>
Which just tells me that the VK CTS is miles better than ours :(
<alyssa>
jenatali: abandon the d3d test suite, replace it with khronos CTS and dozen
<alyssa>
include the glcts run through both dozen+zink and dozen+angle for extra fun
pa has joined #dri-devel
<jenatali>
:P
ElementW has quit [Quit: -]
pa- has quit [Ping timeout: 480 seconds]
rosefromthedead has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: leaving]
ngcortes has quit [Ping timeout: 480 seconds]
<robclark>
jenatali: for your arm devices.. you just need to add turnip support for whatever the windows KMD interface is ;-)
<robclark>
and then you have a vk driver ;-)
<jenatali>
Heh
<robclark>
plus, think what a great QC troll that'd be :-P
<jenatali>
I mean I'm not stopping anybody
<jenatali>
But I don't think that's a job for me
<zmike>
show me where to point the hammer
<jenatali>
I mean WDDM is documented, but each driver has private data that flows, and there's no requirement for a stable ABI because we always have matching UMD/KMD
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
ngcortes has joined #dri-devel
<DavidHeidelberg[m]>
zmike: XDG_RUNTIME_DIR spam - that falls on mine head (I enabled wayland for x86-64 builds......)
<DavidHeidelberg[m]>
Sorry bout that. I'll fix it tomorrow.
<zmike>
np
Zopolis4 has quit []
flto_ has quit []
flto has joined #dri-devel
rosefromthedead has joined #dri-devel
rosefromthedead has quit [Ping timeout: 480 seconds]
Kwiboo has quit [Quit: .]
<jenatali>
robclark: Does turnip lie about vendor IDs for Windows apps?
Kwiboo has joined #dri-devel
<schaeffer>
mohamexiety: well, i tried and failed to get discord installed
<schaeffer>
beyond that, looks like i'm seeing some issue where urxvt goes black and i need to unfocus/refocus the window, but so far so good
<schaeffer>
i mostly do dev stuff on my machines, and a lot of containerized workloads, and docker has worked enough for me so far (haven't tried podman and friends). emacs works too
<mohamexiety>
nice nice
<schaeffer>
my guess is if that's your story you'll probably be alright, but right now audio + gpu + bluetooth is very much WIP so it really depends on what you're looking for. not sure if the camera is going to get support on this thing any time soon either
<schaeffer>
but like i said, i bought it as an arm development machine, so all of those are perks and i'll take them as they come
<schaeffer>
side note: the fanless design is actually surprisingly neat and i didn't think i'd find it as cool as i do
pcercuei has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<robclark>
jenatali: you mean for proton+fex? Idk what is exposed.. iirc turnip has it's own driver-id assigned.. need to check when in front of the codez
<jenatali>
robclark: Yeah basically. I've seen multiple apps that don't like either our driver ID or vendor ID
<jenatali>
I assume you'd run into similar problems by not being one of the big 3 Windows desktop vendors
<robclark>
HdkR has managed to get a bunch of games running.. not sure if that involved some ID spoofing or what
<schaeffer>
mohamexiety: fwiw you can also follow along in #aarch64-laptops
<jenatali>
👍
<HdkR>
jenatali: No spoofing of GPU on my end, but Proton might do it automatically sometimes, I dunno
<jenatali>
Alright, thanks
<HdkR>
I do spoof CPUID vendor strings though, since some game libraries get really pissed if it isn't AMD or Intel. Which I know XTA doesn't spoof that
<jenatali>
Interesting
<jenatali>
I'm not looking at arm64 (at the moment), I just noticed some apps don't like 0x1414 (Microsoft) as the vendor ID
<HdkR>
huh. Maybe these are just applications I've never tested then :P
<jenatali>
I've been chasing DOOM Eternal for a few weeks now, but it's not the only one I've had problems with
<HdkR>
Dang, Doom Eternal uses Denuvo which I haven't nailed down yet. 2016 was fine though
<jenatali>
Ah, too bad
<cheako>
I'm trying to look into presentation, but I couldn't locate `radv_CreateSwapchain` or `radv_GetSwapchainImages`. or rather what's radv_entrypoints?
<jenatali>
cheako: WSI is common across multiple Vulkan drivers in src/vulkan/wsi