tursulin has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
<graphitemaster>
How do driver devs feel about primitive restart
<HdkR>
It's okay, hardware usually isn't super happy about it
<airlied>
well prim restart in GL is kinda not how hw does it, but the fixed index stuff is fine
iive has quit []
<HdkR>
Oh right, arbitrary index is terrible
<graphitemaster>
Yeah Vulkan requires it be the max value of the index type to restart iirc
<graphitemaster>
GL you can program any index value as restart iirc
<graphitemaster>
To me it seems like it would be easy for the HW to support with mesh shading anyways since your index buffer is all software anyways.
<graphitemaster>
GL 4.4 allows primitive rrestart to work with all drawing commands, even non-indexed ones which is funny. Then GL 4.5 changed that rule :(
<HdkR>
sure, mesh shading lets you do whatever you want.
<imirkin>
nvidia has a special bit for whether primitive restart affects draw arrays
q66 has quit []
mbrost has quit [Ping timeout: 480 seconds]
hch12907_ has quit [Remote host closed the connection]
mbrost has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
Duke`` has joined #dri-devel
Dylanger has joined #dri-devel
chivay has joined #dri-devel
cwfitzgerald has joined #dri-devel
Anson[m] has joined #dri-devel
gdevi has joined #dri-devel
enick_722 has joined #dri-devel
kusma has joined #dri-devel
naheemsays[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
pmoreau is now known as Guest52
T_UNIX has joined #dri-devel
itoral has joined #dri-devel
<graphitemaster>
So wave64 was introduced in RDNA right?
<HdkR>
wave32 was introduced
<HdkR>
AMD always had 64 thread waves before that (For hardware that matters anyway)
mattrope has quit [Ping timeout: 480 seconds]
<graphitemaster>
So wave32 is 32-threads per wave, does that just mean a CU can execute more waves at once?
<HdkR>
I don't remember if it does something fancy like two waves per CU when operating in wave32 mode :)
<ishitatsuyuki>
graphitemaster: it's dual issue, the dispatcher executes the instruction for the low wave then the high wave, in lockstep
<HdkR>
There we go, it's cute
<ishitatsuyuki>
the max occupancy is a rather different story
<graphitemaster>
When does the driver decide to use wave32 for graphics/compute workload in GL or Vulkan?
<ishitatsuyuki>
Mesa used to always use wave64 but they recently added some heuristics
<graphitemaster>
Is that something you can even figure out
<ishitatsuyuki>
For Vulkan, it's a better idea to use EXT_subgroup_size_control
<ishitatsuyuki>
graphitemaster: search "wave32" in MRs
<graphitemaster>
Does GL have such an extension?
<ishitatsuyuki>
no
<ishitatsuyuki>
GL, is in general not very good at compute
<graphitemaster>
Well duh, all the useful extensions are not present in GL, like that one.
<ishitatsuyuki>
yeah, yet Khronos is pretending that GL is totally not obsolete ;(
<graphitemaster>
I happen to think compute is pretty reasonable in GL actually, I might be the weird one though.
<graphitemaster>
I mean aside from async compute which never seems to work well on NV anyways.
<HdkR>
Async compute only really works well on something like Turing and newer
<HdkR>
For the Nvidia side
<graphitemaster>
I find the big problem with compute on NV is the mixing of graphics and compute workloads (like interleaved), absolutely poor overlap and tons of context overhead.
<graphitemaster>
Not always possible to do all your compute separate though
<graphitemaster>
So we just do a lot of compute work in vertex shaders instead since it wins on NV still, even as of 3090 RTX
<graphitemaster>
Especially very small compute dispatches
<ishitatsuyuki>
which is pretty much why async compute is important
<graphitemaster>
Someone on Phronoix forums saying wave32 only exists because AMD needed to close the performance gap between them and NV for ray tracing XD
<HdkR>
I hear the Internet comments are always correct.
<graphitemaster>
Yeah, Intel ARC totally going to maek NV bankrupt next month too.
<ishitatsuyuki>
I guess yeah, it's not baseless to say it's for raytracing. But it has been generally convenient that int bits == subgroup size
<graphitemaster>
These comments all suck. I should add to the circlejerk. How about this: "Nintendo tried to sue AMD for calling it Wave64 since that is a trademarked N64 game, thus Wave32 was born" :chefskiss:
<graphitemaster>
The RDNA whitepaper is actually more informative than Internet comment sections. So wave32 splits it intoo 2 32-way SIMD, each executing a 32-thread wave in 1 cycle, with two scalar units and no multiplexing, but rather double-issue
eukara has quit [Remote host closed the connection]
<graphitemaster>
So RDNA is 2x32-SIMD, GCN was 4x16-SIMD, Surprised we did not get wave16 on GCN they could've did the same thing there, quad-issued executing 16-thread wave in 1 cycle
<graphitemaster>
Oh that is literally how GCN worked lol.
<ishitatsuyuki>
I think wave16 is not as easy as it sounds, it requires making the arbiter larger (because waves execute independently instead of lockstep) and it hurts GCN's latency hiding design
<ishitatsuyuki>
It hided the 4 clock latency by grouping operation into 4 consecutive dispatches.
<graphitemaster>
Yeah I'm seeing that now.
<graphitemaster>
Each SIMD16 could execute 1 instruction every 4 cycles
<ishitatsuyuki>
btw, a hidden fact about wave32 & wave64: wave64 gives you better occupancy because the arbiter can schedule either 20 wave32s or 20 wave64s (~= 40 wave32s in terms of occupancy)
<ishitatsuyuki>
but well, as usual, occupancy only matters when you are latency bound
<graphitemaster>
I'm very impressed RDNA has single cycle instruction issue
<ishitatsuyuki>
also on RDNA2 the wave count per CU is reduced to 16
<graphitemaster>
It would stand to reason then GCN wave -> RDNA wave64 should be a 4x performance improvement in pure instruction throughput assuming no IO / bandwidth here
<graphitemaster>
Why is the wave count so much lower in RDNA2
<ishitatsuyuki>
It's 20->16, it takes die space and it probably didn't need that much
<ishitatsuyuki>
iiuc the arbiter is pretty much "brute force", decoding and trying to issue an instruction for all waves each cycle
<graphitemaster>
I still don't fully understand the relationship of waves per SIMD to be honest. I understand an assignment of a wave to a SIMD unit - like if a wave is 32 threads, and the SIMD unit has 32 lanes, then each SIMD is executing 32 threads (I assume wave32 is this), but I don't understand "up to 20 waves per SIMD32", since a SIMD32 cannot execute 20 waves concurrently (that would be 640 threads for wave32)
<graphitemaster>
Is it just a queue of waves and the hardware round-robins it or something?
<ishitatsuyuki>
graphitemaster: do you understand the concept of latency hiding?
<graphitemaster>
So once they're assigned to the wave they cannot move to another wave
<graphitemaster>
er s/wave/simd/
<graphitemaster>
I do understand the concept of latency hiding, yes.
<ishitatsuyuki>
it's a pool of other waves to switch to, while a memory load occurs etc
<graphitemaster>
But my understanding of it was more like how operating system schedulers work, the threads waiting on IO are put to sleep by putting them back on the scheduler queue to be rescheduled.
<ishitatsuyuki>
on RDNA even ALU has latency so it's basically the latency hiding mechanism for everything
<graphitemaster>
And only woken up when the IO comes in of course.
<ishitatsuyuki>
it's very similar to that
<graphitemaster>
So each SIMD unit has basicallyl a 20-wave deep scheduling queue rather than a global queue shared by all SIMDs?
<ishitatsuyuki>
they have a local queue, yeah. but there's also a global queue of course
<ishitatsuyuki>
as the local queue frees up, new work are fetched from the global queue
<ishitatsuyuki>
just keep in mind that unlike OS schedulers there's no guarantee of fairness at all
<graphitemaster>
What is the benefit of having that local queue? Wouldn't that cause scheduling bubbles, can imagine a really expensive wave blocking all 19 other waves on that local queue when they could've run on other available SIMDs but lost a chance to
<ishitatsuyuki>
well the local queue is small enough
<ishitatsuyuki>
you send thousands of waves typically
<ishitatsuyuki>
and how would do context switching at a high rate with global queues?
<ishitatsuyuki>
how would one do*
<cheako>
I tried to play another vulkan game FFXIV and got the same inconsistent result.
<graphitemaster>
If you have a large dispatch sure, but for smaller dispatches that local queue has an effect of under-utilization of other SIMD units
<ishitatsuyuki>
just don't do small dispatches :(
<ishitatsuyuki>
GPUs are not designed for that
<ishitatsuyuki>
the local queue is a mean to allocate resources
Duke`` has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
once you get assigned to a CU, the registers, LDS etc will stay allocated for that wave until it completes
<cheako>
Is this a known limitation of gaming on linux?
<graphitemaster>
How many SIMDs are there per CU anyways
<ishitatsuyuki>
cheako: I'm not sure what you are talking about
<ishitatsuyuki>
I forgot how many SIMDs are there, maybe it's in the presentation?
<cheako>
Since this effectively ends my ability to enjoy playing games... I'll effectively be available every waking moment, so there is no need for a webpage or email somewhere with the same information.
<graphitemaster>
RDNA has WGPs and the # of CUs is 2x the # of WGPs, so I think that is 4 SIMD32s per WGP?
<ishitatsuyuki>
I guess yeah, but I forgot to mention that the arbiter is per SIMD32 not per CU
<graphitemaster>
Slide 15 there is interesting
<graphitemaster>
2 CUs on GCN required 512 threads to reach 100% ALU (2 * 4 * 64)
<graphitemaster>
While WGP only requires 4 * 32 (wave32)
hch12907__ has joined #dri-devel
itoral has quit [Remote host closed the connection]
<graphitemaster>
Oh wow, each SIMD32 has it's own ALU
<graphitemaster>
Unlike the 2 ALU shared by all eight SIMD16 on GCN
<graphitemaster>
Or well, 1 ALU for 4 SIMD
<ishitatsuyuki>
kinda, yeah. it's pretty much the same in terms of die space effficiency though
itoral has joined #dri-devel
mlankhorst has joined #dri-devel
<graphitemaster>
> Compute and vertex shaders usually as Wave32, pixel shaders usually as Wave64
<graphitemaster>
Okay that is the info I needed to know
<graphitemaster>
Thanks for this linkk
<ishitatsuyuki>
the claim about compute is pretty wild
<ishitatsuyuki>
compute is everything
<ishitatsuyuki>
there are obviously cases where wave32 would shine and wave64 would shine
hch12907 has joined #dri-devel
<graphitemaster>
I would really like to expose this as an extension in GL somehow
<ishitatsuyuki>
JOIN KHRONOS! lol
<HdkR>
Or just expose the extension via public interface
<graphitemaster>
No thanks. MESA has their own extensions right? Can I just add it and make a PR?
<HdkR>
You need to get enum numbers reserved still
<HdkR>
Which means going through the Khronos github bits
<ishitatsuyuki>
just use vk
<ishitatsuyuki>
zink would conquer GL in the future anyway
<graphitemaster>
Don't even introduce an enum, introduce a function :P
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
devilhorns has joined #dri-devel
<ondracka>
I want to do a nir pass that transforms sin/cos input to -PI/PI range, https://paste.centos.org/view/a53e9811 however I get infinite loop (likely because it somehow runs recursivelly as the new pattern also includes the original instruction) when I run it with NIR_PASS_V, how to solve this?
Daanct12 has joined #dri-devel
<vsyrjala>
i thought i965 already had one, but looks like that one only adjusts the amplitude slightly
<ondracka>
I'll check i965 to see how it works there, thanks
<vsyrjala>
some intel hw definitely has issues with large input values. the output turns into a triangle wave more or less
Danct12 has quit [Ping timeout: 480 seconds]
<marex>
ondracka: ahoj, try talking to jekstrand I think
<robclark>
handle allocation in userspace would be the remaining the to make bo allocation async
itoral has quit []
<danvet>
robclark, I'm lost on the fence lifetime issue
<danvet>
but userspace selected id is really standard pattern now
<danvet>
well make that client-side selected id
<danvet>
so yeah sure, seems fine to add that to driver's GEM_CREATE ioctl
<danvet>
and add a corresponding interface to drm_gem.c
<robclark>
you can ignore the fence part, unless you really want to dig thru msm_gem_submit ;-)
<robclark>
on gem handle, should there be some setcap thing so userspace tells that it is allocating handles? You can't really mix/match the two schemes
<danvet>
well I have vague memories since I messed around with that recovery path too
<danvet>
or looked at some of your patches
<danvet>
I'm just not clear on why you can end up with fence fd out of sync
<danvet>
or is this strictly only about the msm private fence handles you do?
<robclark>
seqno fence, not dma-fence
<danvet>
the same preallocate trick there should work too, shouldn't it?
<danvet>
yeah but seqno fence should be in lockstep with what userspace does?
<robclark>
for submits that return an fd we still kinda need to sync, but that is done on the host side, not guest side
<robclark>
right
<danvet>
or is that the drm_sched fence that auto-increments?
<danvet>
I got that part of your comment, the PR summary is what confused me
<robclark>
well, it is actually an idr that maps to sched fence
<robclark>
oh, the summary is a bit wrong about fence-fd's
<danvet>
Note that fence-fd's are currently a bit awkward, <- this is the paragraph I don't get
<danvet>
I tried to shuffle fence fds around in my head between guest and host and can't make them break
<robclark>
but drm/virtio creates the guest fence-fd, so that isn't really a problem.. host just needs to keep track of the out-fence-fd to know when it is signaled
mal has joined #dri-devel
<danvet>
like why would a preempt change anything, this stuff should be fixed before we submit the drm_sched_Job
<robclark>
(there kinda needs to be some new guest<->host protocol to do that properly, but that is already been worked on because venus needs it too
<danvet>
so that comment about default priority seems a bit funny
<danvet>
oh what's venus?
<robclark>
vk version of virgl
<danvet>
ah I didn't know the name for that
<danvet>
or forgot
<robclark>
anyways, don't worry too much about the fence-fd part.. it doesn't really apply to keeping host/guest async
<robclark>
what is needed to keep them async, is guest needs to know host gem handle.. and if it can allocate it, that problem is solved ;-)
<robclark>
(well, ignoring things that are immediately mmap'd at least)
<jekstrand>
robclark: It would make dedup no longer a thing
<jekstrand>
Unless we leave import sync
<danvet>
jekstrand, you mean for import?
<danvet>
import is also a different ioctl
<robclark>
hmm
<danvet>
than MSM_GEM_CREATE or whatever it was
<robclark>
I'd have to think a bit about import.. because there is some per-bo state in the kernel (obviously) but also in host userspace
<robclark>
but shared bo's aren't really a hot-path
<MrCooper>
how would such an async scheme deal with BO creation failing on the host?
<robclark>
context-lost
<robclark>
tbh there isn't really good recourse when bo (or submit) fails
<robclark>
I mean, I think current userspace behavior is to segfault ;-)
egbert has joined #dri-devel
<robclark>
danvet: edited description a bit to hopefully explain the priority thing better.. guest needs to be same priority as virglrenderer's egl ctx on host.. it's mostly just an implementation detail, and one of the problems that would be solved by moving host implementation out of virglrenderer
heat has joined #dri-devel
<robclark>
danvet: I suppose what we really want is to have a host-cpu timeline in addition to (per-context) gpu-timelines.. but the ring_id thing added in drm/virtio should basically give us that
mort_8 has left #dri-devel [#dri-devel]
<danvet>
robclark, ah I think I get it, you have contexts directly created by the client and managed there and then stuff that goes through virglrenderer on the host, and if they run out of order it's a mess?
<robclark>
right
<danvet>
yeah that's a fun problem :-)
<danvet>
but also doesn't sound any different from having a copy engine for uploads that's async from rendering
<robclark>
the problem is really just an implementation detail.. totally solveable.. just not solved yet
<danvet>
yeah
Duke`` has joined #dri-devel
JosExpsito[m] has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
mntmn has joined #dri-devel
ZeZu has quit [Quit: off to see the wizard]
ZeZu has joined #dri-devel
justchecking has joined #dri-devel
ybogdano has joined #dri-devel
justchecking has quit [Remote host closed the connection]
jernej_ is now known as jernej
ceyusa has joined #dri-devel
lemonzest has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
lanodan_ has joined #dri-devel
<cheako>
Hi, so I went to open an issue as suggested and following the instructions I'd need to upgrade to `git main`. This is fine, however going through all the work of setting up a build environment, I'd much rather spend my time investing in setting up a nightly or CI apt repository.
aravind has joined #dri-devel
<cheako>
I'm running debian and where I got hungup is cross compiling for i386, for wine32.
ella-0_ has joined #dri-devel
gouchi has joined #dri-devel
<Venemo>
cheako: you mean cross-compiling mesa?
ella-0 has quit [Read error: Connection reset by peer]
<cheako>
So yes, my time would be better spent writing a CI that does the build in a docker.
<Venemo>
Or just use a sane distro
<cheako>
Actually, it's all the issue trackers fault for asking the impossible.
<Venemo>
Well... it's possible on other distros
<anholt>
if anyone's up for acking some mechanical changes, the first two tgsi/ntt commits of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14404 would really help push forward the removal of glsl-to-tgsi (and incidentally help i915 a ton).
anparra[m] has joined #dri-devel
dwlsalmeida has joined #dri-devel
<jekstrand>
Got an implementation of VkRenderPass on top of dynamic rendering! Now to figure out why most of crucible fails. :-)
marcan has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Remote host closed the connection]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
mwk has joined #dri-devel
Bennett has joined #dri-devel
<cheako>
That's too big a change, running git main, I get 7fps and can no-longer cause the swapchain to be recreated as easily.
<cheako>
I should be able to get 40fps, per testing.
iive has joined #dri-devel
<cheako>
Yeah, I'll have to add invalidating the swapchain to my layer... At least then I can have it trigger once every 4k frames or something.
aravind has quit [Ping timeout: 480 seconds]
<sravn>
tzimmermann: Holler if you need extra review on "Fix and improve fbdevio clipping" before you can apply and move on.
<sravn>
tzimmermann: If you just want to wait to see if you get extra inputs I will happily ignore it as javierm already did a nice review
tzimmermann has quit [Quit: Leaving]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
shankaru has quit [Quit: Leaving.]
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
lanodan_ has quit []
lanodan has joined #dri-devel
aswarup_ has joined #dri-devel
aswarup_ has quit [Remote host closed the connection]
<idr>
anholt: I think cmarcelo and I got those first two for you.
<anholt>
I don't know about windows. I would recommend checking mesa/mesa/pipelines to see what the last runs that did windows did.
jjardon___ has left #dri-devel [#dri-devel]
qyliss has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
devilhorns has quit []
<jenatali>
Seems like a transient error to me
gpiccoli has quit [Server closed connection]
mwalle has quit [Server closed connection]
gpiccoli has joined #dri-devel
adavy has joined #dri-devel
mwalle has joined #dri-devel
linkmauve has left #dri-devel [#dri-devel]
linkmauve has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
ambasta[m] has quit [Server closed connection]
ambasta[m] has joined #dri-devel
shankaru has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
shankaru has quit [Ping timeout: 480 seconds]
lkw has quit [Quit: leaving]
shankaru has joined #dri-devel
nchery has joined #dri-devel
linkmauve has left #dri-devel [#dri-devel]
DPA- has quit [Server closed connection]
linkmauve has joined #dri-devel
DPA has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
hikiko has quit [Server closed connection]
pnowack has quit [Quit: pnowack]
Viciouss5 has quit [Ping timeout: 480 seconds]
hikiko has joined #dri-devel
moony has quit [Server closed connection]
moony has joined #dri-devel
bgs has quit [Server closed connection]
bgs has joined #dri-devel
jkqxz has quit [Server closed connection]
jkqxz has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
Viciouss5 has joined #dri-devel
Viciouss5 has quit []
Viciouss has joined #dri-devel
Haaninjo has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
jcristau has quit [Server closed connection]
jcristau has joined #dri-devel
gouchi has quit [Remote host closed the connection]
mupuf has quit [Server closed connection]
mupuf has joined #dri-devel
<jenatali>
If I wanted to add driconf entries for cross-platform apps, that use <name> for their Linux executable and <name>.exe, would people strongly prefer that I figure out how to make regex work on Windows or would it be acceptable to just duplicate the existing Linux entries?
mlankhorst has quit [Ping timeout: 480 seconds]
<jenatali>
Or should I just add a generic rule to driconf parsing that .exe can be omitted and still match without having to regex it?
rasterman has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Remote host closed the connection]