ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Walt has joined #dri-devel
<Walt> How would I interface to Mesa APIs?
<FLHerne> Walt: Please ask a more specific question ;-)
<airlied> or state what you want to do
<FLHerne> Mesa exports or implements *loads* of APIs for completely different things
<Walt> I want to run a api through the Mesa driver more directly similar to what d3d9 does
<Walt> in wine
<FLHerne> Walt: You want to *implement* an API similar to D3D9 in a Mesa-based driver?
<Walt> No
<FLHerne> Look at src/gallium/frontends and write a new one
<airlied> there already is the d3d9 frontend
<airlied> it's called nine
<FLHerne> Walt: then I still can't understand what you're asking :-/
<Walt> I want to write a API that uses some of Mesa's APIs directly outside of the API
<HdkR> but why?
<Walt> just cuz
<HdkR> Are you hoping to get better performance or lower overhead? Because VKD3D already does that quite well
<airlied> Walt: we don't export a stable api at the level you want, you have to put that sort of thing in-tree or just fork mesa into whatever project
<Walt> Wait, vkd3d is good now?
<FLHerne> HdkR: pretty sure the 'd3d9' is just an example, but an example of what exactly I'm less sure of :-/
<HdkR> "just cuz" is too broad. If you're wanting to expose internal APIs to hook up RedGPU API then I'm sure people won't be enthused :P
nsneck has quit [Remote host closed the connection]
<Walt> I heared on #nouveau that wine used internal apis to implement d3d9, but ig I was proved wrong
<FLHerne> Like airlied said there's a D3D9 frontend in Mesa, see src/gallium/frontends/nine
<Walt> I see
<FLHerne> So you might not be wrong, but it's very difficult to understand what you actually mean to ask
<FLHerne> There's no stable external API at the gallium-driver level, it's just part of mesa
<FLHerne> although at least the vmware driver is proof that you *can* maintain an out-of-tree gallium frontend
<airlied> wine by default uses OpenGL or Vulkan, nine is an optional external option to go direct to the nine interface
<HdkR> Which then nine is no longer an internal API. It's an API :P
<kisak> there also should be a disctinction made between the winehq maintained vkd3d and Valve maintained vkd3d-proton, which are completely independent implementations of d3d12 to vulkan
<kisak> ... and a couple minutes later I realized I mistyped, vkd3d and vkd3d-proton are significantly different implementations, but they do have common elements elsewhere that might be shared, so *completely* is incorrect in my last sentence
<DrNick> they diverged in 2019
<DrNick> I have a rubric somewhere that lists all the Vulkan-based D3D implementations because there were like 5 of them of various provenances
<Walt> Whats the best documented Mesa frontend with gallium
illwieckz has joined #dri-devel
<airlied> Walt: I doubt any of them are that well documented, nine might be the simplest if you familiar with d3d9
<airlied> lavapipe does a crappy vulkan on gallium impression, which might be okay if you understand vulkan
<airlied> and then the main mesa state tracker is probably the most complex
<Walt> What is lavapipe?
<Walt> Im not that familliar with d3d9, but I am quite familiar with vulkan
<airlied> it's a vulkan frontend for gallium software rasterisation
<airlied> it's also a proof of why you can't layer vulkan/d3d12 on top of gallium in the real world
<Walt> So it converting vulkan to gallium?
<airlied> yes
<airlied> it records everything to a cpu command buffer, then dispatches it to gallium contexts
<Walt> Wait, why doesnt nouveau use this??
<airlied> it's also a proof of why you can't layer vulkan/d3d12 on top of gallium in the real world
<airlied> I think that covers why you can't use it
<Walt> Oh, its that shit?
<airlied> it not workable for real hardware
<airlied> and never will be, writing a vulkan driver is a lot less effort
<Walt> Whats the main problem with it rn
<airlied> recording everything to a cpu command buffer is not how vulkan is meant to be used
<airlied> memory allocation isn't workable either
<Walt> Oh, and that messes with everything how though?
<Walt> oh
<airlied> since gallium exposes objects, but vulkan wants objects and memory allocations to be separate things
<airlied> lucky I wrote that :-P
<Walt> Does anything work at all? GZDoom perhaps?
<airlied> no
<airlied> there is no way to make the frontend work on any backend except llvmpipe
<airlied> esp now a hw backend
<airlied> not a hw backend
Walt has quit [Remote host closed the connection]
* airlied scared them awa
* airlied scared them away
<HdkR> Developers talking to users tends to do that
JohnnyonFlame has quit [Read error: Connection reset by peer]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
X-Scale` has joined #dri-devel
X-Scale has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
adjtm is now known as Guest5888
adjtm has joined #dri-devel
Guest5888 has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
khfeng has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
sdutt_ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
The_Company has quit [Ping timeout: 480 seconds]
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
shashank_sharma has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
<OftenTimeConsuming> Forgot to compile nouveau support into mesa, and it still works, nice.
<imirkin> probably better than before
<OftenTimeConsuming> Well I still have some issue where one DVI port doesn't operate, but that'll probably go away when I install the driver and upgrade to Linux 5.15.2.
<OftenTimeConsuming> Reclocking is mostly operational on Fermi huh?
<imirkin> i think "not at all" is a better description
<imirkin> there's a branch, which allegedly works on a single physical board. i have a board that should be identical, and it didn't work there.
<imirkin> otoh display should work pretty well, but has nothing to do with mesa
Duke`` has joined #dri-devel
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
<OftenTimeConsuming> Nope, more broken, time to downgrade.
<imirkin> oh, right, fermi
<imirkin> there's been a recent kernel regression
<imirkin> which affects fermi
<OftenTimeConsuming> Which version?
<imirkin> it has lasted a while
<imirkin> 5.10 -> 5.14 or so?
<OftenTimeConsuming> SO I need to go for 5.4.159?
<imirkin> not sure which options are available to you...
<OftenTimeConsuming> I can compile whatever as Gentoo.
<imirkin> i guess broken since 5.12
<OftenTimeConsuming> Thanks, lets see if that patch works
<imirkin> should be in the next drm-next pull
<imirkin> (if not pulled into master already)
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
cef has quit [Quit: Zoom!]
<OftenTimeConsuming> Yeah, the patch didn't fix anything, I got a different regression.
<imirkin> ok
<imirkin> more info welcome.
<imirkin> or downgrade and hope someone else runs into the same problem you do.
kmn has joined #dri-devel
itoral has joined #dri-devel
<OftenTimeConsuming> imirkin: Downgraded but same issue. 5.15.1 without the Xorg nouveau driver installed; DVI-0 works on bootup, but is disabled on modesetting, where the other 2 outputs work and 2 displays work fine, but DVI 0 doesn't enable. 5.15.2 with the Xorg nouveau driver: same DVI 0 issue, but the microHDMI display just shows a corrupted mess (but the mouse displays fine). 5.4.159: DVI 0 issue
<OftenTimeConsuming> and microHDMI issue still.
<imirkin> i can't _quite_ tell what you're trying to do
<imirkin> but
<imirkin> fermi only supports up to 2 displays at a time
<imirkin> irrespective of the number of connectors
<OftenTimeConsuming> Oh, arbitrary restrictions from the friendly nvidia huh?
lemonzest has joined #dri-devel
<imirkin> OftenTimeConsuming: i mean ... arbitrary in that they arbitrarily chose to have 2 CRTC's in the hardware
<imirkin> which is more than 1 but less than 20...
<imirkin> but they were nice enough to give people some choice in the connectors they could use to connect to their screens
<imirkin> but just coz a connector's there doesn't mean you can use all of them at once
<imirkin> this is true of every manufacturer afaik
<imirkin> (esp once DP-MST comes into play)
<OftenTimeConsuming> They could have easily put 3 even so. Anyway, with only 2 connectors the issue goes away and I have 2 screens and sadness.
sdutt_ has quit [Ping timeout: 480 seconds]
<imirkin> yay sadness
Duke`` has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
thellstrom has joined #dri-devel
<OftenTimeConsuming> Or I can just use Intel integrated huh?
<OftenTimeConsuming> Nice cinematic experience though.
thellstrom1 has quit [Ping timeout: 480 seconds]
cef has joined #dri-devel
tzimmermann has joined #dri-devel
jkrzyszt has joined #dri-devel
<imirkin> intel has oodles of restrictions on the number of outputs used as well
<imirkin> or you mean slaving an output? that probably won't be great. maybe try it with intel as the primary. if the fermi had reclocking, then maybe
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<HdkR> At least the very latest Intel chips support four displays :D
<OftenTimeConsuming> imirkin: Well the one I have does 3, though the 3rd port is VGA, so I get a nice washed-out image.
<imirkin> HdkR: so do the very latest nvidia chips
<imirkin> (in fact all since the gen *after* fermi...)
<imirkin> among other things, for a very long time intel didn't support dual-link dvi
<imirkin> (still doesn't, but now it's all done through DP adapters, i presume)
<HdkR> Yea, Nvidia is still lacking the six that AMD has sadly
thellstrom has quit [Remote host closed the connection]
<imirkin> HdkR: nvidia's got you covered ... just slap 2 GPU's on a single board and call it 8 displays.
thellstrom has joined #dri-devel
<imirkin> no one will notice.
<HdkR> Until you see all the stuttering as the OS tries compositing everything
<imirkin> by then it's too late. you bought the board.
<imirkin> e.g. this friendly fellow:
<HdkR> Dang, Nvidia got the money. I hear though that the more I buy, the more I save.
<OftenTimeConsuming> The more you buy, the more proprietary it gets.
<imirkin> yeah, you buy a few RTX 3090's, you'll save enough to buy a GTX 1650 :)
<HdkR> You can't buy a few 3090s, they're all sold out :D
thellstrom1 has joined #dri-devel
<imirkin> so you'll save even more then ;)
<OftenTimeConsuming> All GPU's are sold out currently, as they can't be bothered to increase production when everything is selling.
<HdkR> Only ponte vecchio can save us from sold out GPUs
thellstrom has quit [Ping timeout: 480 seconds]
<OftenTimeConsuming> Hmm, the only solution to all these graphics problems is to design and write your own libre GPU in verilog and then get it produced - good luck sourcing libre memory chips etc with all the current backlogs though.
<airlied> the libresoc team is off making a router now or something
<imirkin> that sounds much easier.
<OftenTimeConsuming> Librerouter?
thellstrom1 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
camus has joined #dri-devel
pnowack has joined #dri-devel
<OftenTimeConsuming> Of course, suspend fails to actually operate and the driver prefers to just hang on resume. Thankfully I can at least shutdown cleanly via the powerbutton (which does swap to displaying the shutdown log).
camus1 has quit [Ping timeout: 480 seconds]
rg3igalia__ has quit []
rg3igalia__ has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has joined #dri-devel
<MrCooper> columbarius: re , why should a BO allocated with implicit modifiers and GBM_BO_USE_LINEAR not be treated the same as one allocated with the DRM_FORMAT_MOD_LINEAR modifier?
camus has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
anarsoul|2 has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
slattann has joined #dri-devel
tolszak has joined #dri-devel
tursulin has joined #dri-devel
<columbarius> MrCooper, emersion, daniels: I didn't found it in my logs with a quick search, but if i remember correctly the point was that the API has no guarantee that they are compatible.
<emersion> MrCooper: daniels NACKed this iirc
<emersion> in general, you can't strip modifiers
<emersion> if you get LINEAR, it gets tempting to strip it
<MrCooper> this is more like the opposite of stripping, attaching DRM_FORMAT_MOD_LINEAR to a buffer that was allocated without any explicit modifiers
<emersion> but the other side (the importer) will need to strip
unidan has joined #dri-devel
<emersion> it's simpler if INVALID means implicit mods, and not-INVALID means explciit mods
<emersion> than having weird cases like "LINEAR may mean both"
<bnieuwenhuizen> FWIW I'd like to reserve the right to make stride mean different things with modifers than without
<emersion> bnieuwenhuizen: interesting, even with LINEAR?
<MrCooper> bnieuwenhuizen: modifiers don't mean anything for stride
<bnieuwenhuizen> (given that on AMD stride means something different than in the core kms code)
<bnieuwenhuizen> hmm, I guess it wouldn't matter for linear
<MrCooper> specifically, DRM_FORMAT_MOD_LINEAR doesn't
<emersion> MrCooper: modifiers may change the meaning of stride. but yeah not for LINEAR
<emersion> well, "meaning"
<bnieuwenhuizen> the diff is mostly that core kms assumes stride is in whole tiles while AMD does width in pixels * bpp
<bnieuwenhuizen> and we could do a flag switch with new modifiers one day to fix that, but wouldn't if userspace makes assumptions. Of course no diff with LINEAR (and we couldn't flag day that anyway)
<daniels> emersion, columbarius: I'm fine with GBM_BO_USE_LINEAR or other-API equivalents being aliased to DRM_FORMAT_MOD_INVALID, because in that case you sort of have allocated with modifiers really
<emersion> ah, i remembered our last discussion incorrectly then
<MrCooper> daniels: I hope you mean DRM_FORMAT_MOD_LINEAR :)
<emersion> ah, no
<daniels> MrCooper: er, yes
<emersion> ok
<emersion> MrCooper: but why do you want to send trhe buffer with LINEAR then?
<emersion> sounds like this would just confuse clients which don't support explicit modifiers
<MrCooper> I didn't start the discussion I referenced above, but I'd assume it's about being able to use a modifier-less buffer with modifierful APIs
<emersion> ah, vulkan maybe?
<daniels> Vulkan can do modifiers tho ...
<emersion> but then the producer can just use the modifier-ful APIs instead
<daniels> VA-API is more patchy
<emersion> vulkan can';t do implicit modifiers
<emersion> so a modifier-less producer won't work with a vulkan consumer
<daniels> I should maybe step out of this conversation until I've had more coffee. yes, that makes perfect sense.
<columbarius> unless the producer uses the _USE_LINEAR flag?
<emersion> i haven't read the discussion linked, so not sure if all of this makes sense either
<emersion> producer with USE_LINEAR should work with vulkan consumer if the consumer advertises the LINEAR mod
<emersion> err
<emersion> if the producer* advertises the LINEAR mod
<emersion> but it would be better to just add modifier support to the producer instead
<columbarius> ok to summarize, announcing _MOD_LINEAR, when the implicit api is used with _USE_LINEAR is acked as a stop gap measurement with preference for using the full modifier aware api?
imre has quit [Ping timeout: 480 seconds]
<emersion> yea
<emersion> announcing LINEAR when using the modifier-less API, and making that allocate with USE_LINEAR in GBM, is fine
<emersion> but full modifier support is better
* columbarius cries in polaris
imre has joined #dri-devel
slattann has quit []
pnowack has quit [Quit: pnowack]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
sneil has quit [Remote host closed the connection]
sneil has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
itoral has quit []
adjtm has joined #dri-devel
nchery is now known as Guest5937
nchery has joined #dri-devel
nchery is now known as Guest5938
nchery has joined #dri-devel
Guest5937 has quit [Ping timeout: 480 seconds]
Guest5938 has quit [Ping timeout: 480 seconds]
nchery is now known as Guest5940
nchery has joined #dri-devel
Guest5940 has quit [Ping timeout: 480 seconds]
Akari` has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
Akari` has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
shashank_sharma has quit [Remote host closed the connection]
shashanks has quit [Remote host closed the connection]
shashank_sharma has joined #dri-devel
<danvet> mripard, <- drm-misc-fixes ready?
<danvet> i.e. ff to -rc1 or backmerge -rc1 or whatever
<danvet> airlied, I pushed -rc1 to drm-fixes to prep and all that
<danvet> mripard, ^^ in case backmerge needed
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
vyivel has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
emersion has joined #dri-devel
vyivel has joined #dri-devel
<mripard> danvet: I did the backmerge, I'm test-compiling
<mripard> thanks
<danvet> emersion, state_json?
<emersion> that would be nice
<mripard> danvet: hmm, actually I forgot to fetch the new drm-fixes branch, and it doesn't merge properly in drm-tip?
<danvet> mripard, oops
* danvet goes and fixes that
khfeng has quit [Ping timeout: 480 seconds]
tolszak has quit [Ping timeout: 480 seconds]
Surkow|laptop has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
tolszak has joined #dri-devel
macromorgan is now known as Guest5946
macromorgan has joined #dri-devel
Guest5946 has quit [Remote host closed the connection]
macromorgan is now known as Guest5948
macromorgan has joined #dri-devel
Guest5948 has quit [Read error: Connection reset by peer]
<daniels> danvet: you can be the one to send the PR for an in-kernel JSON serialiser if you like
emersion has quit [Read error: No route to host]
emersion has joined #dri-devel
vyivel has quit [Read error: No route to host]
bl4ckb0ne has quit [Write error: connection closed]
ddevault has quit [Read error: No route to host]
vyivel has joined #dri-devel
bl4ckb0ne has joined #dri-devel
Surkow|laptop has joined #dri-devel
ddevault has joined #dri-devel
<danvet> daniels, I'll go full send on that meme
slattann has joined #dri-devel
<daniels> danvet: unsure if you're aware that 'send it' is Australian slang for committing to doing something monumentally stupid or not :)
<HdkR> Ship it!
fxkamd has joined #dri-devel
<danvet> daniels, well yeah :-)
<danvet> I mean, meme'ing and shitposting is generally pretty stupid
dsrt^ has quit [Remote host closed the connection]
tolszak has quit []
pnowack has joined #dri-devel
* tomeu is surprised at the number of panfrost users tracking mainline/master, by the number of reports I have got regarding the drm_sched_job_add_implicit_dependencies fix
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
* jekstrand both loves and hates Fedora's automatic debug info downloads
<danvet> tomeu, I thought there's also some etnaviv reports mixed in?
<tomeu> those didn't reach me :)
i-garrison has quit [Ping timeout: 480 seconds]
<imirkin> how does one declare an image as "coherent" in opencl (like the coherent modifier in GL)
anarsoul|2 has quit []
anarsoul has joined #dri-devel
i-garrison has joined #dri-devel
mattrope has joined #dri-devel
<jenatali> imirkin: What's it do in GL?
<jenatali> I'm pretty sure there's no equivalent in CL
<imirkin> jenatali: makes it so that stores have to show up in later reads
<jenatali> Ah, so every store is effectively a barrier then?
<cwabbott> no, that's not quite right
<imirkin> no, that's too strong
<cwabbott> it makes stores appear to other invocations after the appropriate fence
<cwabbott> without coherent, they might not show up until after the shader is done
<imirkin> afaik a perfectly valid implementation of image stores would be to queue them all up, and emit at the end of the shader
<imirkin> with coherent, that is not a valid impl
i-garrison has quit []
i-garrison has joined #dri-devel
<imirkin> anyways, i just realized i should be able to use GL to achieve the effect i need as well, so no need for CL-based things.
<cwabbott> it wouldn't be correct, I think
<jenatali> > For images declared with the read_write qualifier, the atomic_work_item_fence must be called to make sure that writes to the image by a work-item become visible to that work-item on subsequent reads to that image by that work-item.
<imirkin> cwabbott: if you ignore atomics :)
<cwabbott> stores are always coherent inside the same invocation even without coherent
<cwabbott> so no, even if you ignore atomics it's not right
<imirkin> how so?
<imirkin> if you queue them all up to the end, who's gonna know
<cwabbott> you can read them again in the same invocation
<imirkin> mmmmmmm you sure? that would make what freedreno does not work.
<cwabbott> yes, exactly, what freedreno does doesn't work :)
<imirkin> hehe ok
<imirkin> well, it's all blob-inspired. i'll double-check
<imirkin> i don't think there are any tests which are sensitive to this
<imirkin> (except the coherent ones)
<cwabbott> and i believe coherent doesn't actually do anything on qcom
<imirkin> allegedly makes it use image loads vs texture loads
<cwabbott> yeah, as i said that's wrong
<imirkin> but that's what it does on qcom.
<cwabbott> qcom is probably inferring readonly
<imirkin> i have traces where it's using the texture cache at the very least.
<imirkin> and then image store.
jewins has joined #dri-devel
<imirkin> i'll double-check some stuff.
<cwabbott> i'd certainly be surprised if that was correct
<cwabbott> it would mean that the texture cache isn't truely read-only
<imirkin> just coz the blob does it doesn't make it correct of course ;)
<cwabbott> :)
<jenatali> From skimming the GL wiki, both readers and writers have to use coherent for it to be guaranteed, so I think using the texture cache without coherent would be valid
<jekstrand> bnieuwenhuizen: How much desire do you have to review the common sync code before it lands?
<cwabbott> jenatali: that's only if readers and writers are in different invocations
<jekstrand> bnieuwenhuizen: dj-death has reviewed it all now
<jenatali> cwabbott: Oh, sure
<jenatali> I'd expect a shader compiler to realize that the same image is read and written in the same invocation and use the right caching behavior to produce coherence there I guess
<cwabbott> jenatali: I think I have a lower expectation of compilers than you do :)
<jenatali> :P fair
<cwabbott> so, in mesa we generally only try to track if the overall resource is only read
<jenatali> Anyway from what I understand, it seems you need both barriers + coherent in order for reads to be valid in another work item than writes?
<imirkin> when you're the one writing the compiler, those expectations go down _fast_
<cwabbott> yes, that's right
<jenatali> If that's right, then in CL coherent is implied, so you just need to also insert the right barriers
<jenatali> Out of curiosity, is there a defined behavior when you use the right barriers without declaring it coherent? Or is it just undefined if you don't get both correct?
<cwabbott> it's just undefined
<cwabbott> non-coherent is really meant for cases where you dump a bunch of data that's read by the CPU or another compute dispatch
<jenatali> Ok so in theory a valid implementation would be to ignore explicit barriers and just always do the right thing on writes, and a different valid implementation would be to ignore the qualifier and just do everything during explicit barriers?
<cwabbott> or if you really want to be technical, it's meant to map to GLC=1 on AMD (if you're familiar with that)
<cwabbott> yes, that's right I think
<jenatali> Ok, I think I get it then, thanks. D3D has the same behavior FWIW (we call it "globally coherent" rather than just "coherent") and I didn't quite fully grasp it
<cwabbott> some implementations (AMD) have a non-coherent per-core L1 cache which still supports mixed reads and writes
<cwabbott> coherent lets you "punch through" and skip that cache
<cwabbott> vulkan memory model added make available/make visible which let you flush/invalidate it
<jenatali> One of these days I'll do a deeper dive into that
<cwabbott> some vendors, like qcom (which i'm working on now) don't have it and this all just gets ignored
milkylainen has joined #dri-devel
<cwabbott> practically everyone requires some kind of fence though
<jenatali> Yeah makes sense
tzimmermann has quit [Quit: Leaving]
<jekstrand> dj-death: I've got patches to fix GetPhysicalDeviceExternalSemaphoreProperties with the new impl:
<jekstrand> They're sitting on my jenkins_vulkan branch
* jekstrand needs to reboot or something. Copy+paste decided to not work.
<jekstrand> brb
<anholt_> imirkin: that's the --timeout arg
<imirkin> anholt_: aha, awesome. will check it out.
<imirkin> it wasn't in --help
<jenatali> imirkin: Thanks for making me realize that vtn should add "coherent" to CL read-write images... and I think our DXIL backend doesn't know how to emit that so I need to add that too
<imirkin> jenatali: sorry for making more work for you ;)
<jenatali> Heh, no worries, it's a good bugfix (probably)
<jenatali> Though I guess read-write images are CL2.0 which we haven't really tried to claim support for yet
<anholt_> imirkin: deqp-runner run --help rather than just --help :)
<imirkin> jenatali: should still support coherent in your backend for GL's sake though?
<jenatali> imirkin: We haven't gotten to GL4 that adds storage images
<jenatali> But yeah for VkOn12 and WebGPU and now CL we need it
<imirkin> jenatali: oh. for some reason i thought you were covered all the way to the end
<jenatali> No, currently GL3.3 core (3.1 compat), CL1.2
<jenatali> One of these days I'll get time to push those forward more
<imirkin> why no GL 3.3 compat? trouble with GS + clipvertex? :)
<jenatali> Honestly I'm not sure
<imirkin> hehe ok
<jenatali> I suspect there's some combination of GS + some other feature that isn't implemented, but I haven't tried turning it on and seeing what blows up to know what's missing
<imirkin> probably better things to do?
<imirkin> might be a quick win though, since you're not actually implementing the functionality
<imirkin> and the underlying drivers almost certainly support this stuff
<jenatali> Yeah, got a laundry list of things I need to get to, but I suspect relatively soon I'll get some time to dig in more
iive has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<jekstrand> dj-death: Just added two fixup patches to vk-common-sync and kicking through Jenkins one more time.
<jekstrand> dj-death: The drm syncobj one is rebase fail, I think. The other is for the CTS issue I made that gerrit change for.
slattann has quit []
ybogdano has joined #dri-devel
camus1 has joined #dri-devel
gouchi has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
bgs has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
bgs has quit [Read error: Connection reset by peer]
bgs has joined #dri-devel
jbarnes_ has quit []
jbarnes_ has joined #dri-devel
jbarnes_ has quit []
jbarnes has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
fxkamd has quit [Remote host closed the connection]
<bnieuwenhuizen> jekstrand: can you give me 24 hours to review the rest?
gouchi has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
<bnieuwenhuizen> mostly to see how many holes I can poke in the submission and the timeline emulation path
<anholt_> making sure I understand some spec right: a shader doing x = imageLoad(coords); imageStore(coords, val); should get the original image contents and not the new val, even with no barrier in between, right?
abhinav___ has joined #dri-devel
gouchi has joined #dri-devel
pnowack has quit [Quit: pnowack]
macromorgan has quit [Ping timeout: 480 seconds]
<jekstrand> bnieuwenhuizen: Sure
<jekstrand> anholt_: correct
macromorgan has joined #dri-devel
<jekstrand> Bah! Something's deadlocking again.
macromorgan is now known as Guest5968
Guest5968 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<anholt_> jekstrand: thanks. turns out our noncoherent loads are a little extra incoherent.
<jekstrand> hehe
<jekstrand> anholt_: At least with the Vulkan memory model, you always have to obey shader ordering and, I think, it always has to be correct assuming the same coords on the same shader invocation.
<jekstrand> I'm not 100% sure about the later in the world of non-coherent stuff.
<anholt_> coherent's just supposed to be about cross-invocation.
<jekstrand> Yeah. :)
pnowack has joined #dri-devel
<jekstrand> anholt_: Not sure if you're the one to poke but I just saw Phoronix say turnip supports 1.2. That means timeline semaphores. And, since I now distrust all timeline semaphore implementations, I recommend someone on the turnip team take a look at !13427 and plan to convert once it lands. Assuming bnieuwenhuizen and dj-death sign off on my fixups, that'll probably be tomorrow.
<jekstrand> danylo, cwabbott: ^^
ybogdano has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<danylo> Ok, thanks
i-garrison has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
<jekstrand> Should let you drop about 3k lines of driver code if ANV is a good indication.
macromorgan is now known as Guest5970
Guest5970 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<jenatali> Is there anyone in particular who should review mapi/TLS changes? Looking for someone to review
<jenatali> Should be pretty Windows-specific I think
<jekstrand> ugh
<jekstrand> I think idr has done some work in that area
<jekstrand> For other Windows people, maybe Jose Fonseca?
<jenatali> Yeah, guess I can ping them. I don't think they'd care since it only impacts shared-glapi, which they wouldn't be using
<jekstrand> Yeah
<jekstrand> That's a hard one.
<jekstrand> You might be looking for a pity review. :-/
ybogdano has joined #dri-devel
<jenatali> Yep, figured as much
<jenatali> Mainly I just want to make sure that enabling EGL/GLES doesn't regress perf or correctness - there's a known ordering bug that I wasn't confident enough to fix in the not-ELF-TLS path
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest5973
macromorgan has joined #dri-devel
Guest5973 has quit []
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<robclark> anholt_, cwabbott, danylo: btw it looks like we don't set the `DRIVER_SYNCOBJ_TIMELINE` bit in `drm_driver::driver_features` yet.. although I'm not sure the reasoning for that or whether it is intentional..
<robclark> maybe bnieuwenhuizen knows?
<bnieuwenhuizen> robclark: no userspace implementing the vulkan extensions -> mostly untested
<bnieuwenhuizen> not even sure if it was complete or me just designing the IOCTL in a compatible way to avoid having to extend it later
<robclark> hmm, ok.. I guess that isn't needed for timeline semephores then?
<anholt_> I think we only have non-shared timeline semaphores so far
<anholt_> (3f229e34c9793b71001f85e08ef64b7f33565d50)
<bnieuwenhuizen> it is needed if you want to make them cross process shareable since the emulation won't work cross process
YuGiOhJCJ has joined #dri-devel
camus1 has joined #dri-devel
<robclark> ic
camus has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen> jekstrand: feel free to marge if you want to
<jekstrand> bnieuwenhuizen: Thanks. Still waiting on dj-death to review a couple squash-ins
<jekstrand> bnieuwenhuizen: RE: sparse. Ugh, yeah. That's going to need a lot of the same mechanism.
<jekstrand> bnieuwenhuizen: Do you have a kernel queue for it or do you do it all on the userspace CPU timeline?
<bnieuwenhuizen> all userspace but we need to deal with the wait-before-submit thing
<bnieuwenhuizen> so in radv we just extended the submit struct with arrays of sparse binding commands next to cmdbuffers
<jekstrand> bnieuwenhuizen: Sure. Just wondering if you want all the waiting to happen in rumtime code or if you only want the runtime code to do enough sync management to do the re-ordering.
<jekstrand> But, yeah, I figured it'd be implemented by adding some sparse binding structs to vk_queue_submit
<jekstrand> Otherwise, it's a lot of duplication
<bnieuwenhuizen> only the PENDING waits
<bnieuwenhuizen> which is pretty much what it does already :)
<jekstrand> yup
<jekstrand> Might want to have separate driver_submit and driver_bind_sparse entrypoints
<jekstrand> Or maybe do it all in driver_submit?
<bnieuwenhuizen> well even with driver_bind_sparse one would still also call driver_submit to signal the syncs
<bnieuwenhuizen> but no strong opinion here. Keeping it separate is probably how ti goes anyway, but whether that is a separate callback or an if at the start of the single callback :shrug:
fxkamd has quit []
<jekstrand> bnieuwenhuizen: Are your binds immediate?
<jekstrand> If so, you can do vk_sync_signal()
<jekstrand> That'll work for all the syncobj cases, anyway
<bnieuwenhuizen> kinda. It is all some slightly stronger implicit sync across the entire drm fd
<jekstrand> Or is it some deferred thing which only latches on the next submit?
<bnieuwenhuizen> so technically it can latch on the enxt submit but you can't really observe
<jekstrand> k
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
pcercuei has quit [Quit: dodo]
jkrzyszt has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
iive has quit []