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>
<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>
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.
<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?
<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 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
<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]
<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]
<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
<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]