ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pnowack has quit [Quit: pnowack]
<idr> Holy smokes.
<idr> Unless I derped the patch, there are 1,600+ shaders in shader-db that have that pattern.
<imirkin> probably worth doing a spot-check, in case you didn't do like textureBias(any-immediate) -> texture()...
<imirkin> [yeah, bias is an implicit arg, but that's harder to show as syntax]
alatiera has quit [Remote host closed the connection]
alatiera has joined #dri-devel
gawin has joined #dri-devel
alatiera is now known as Guest5465
loki_val has joined #dri-devel
<jekstrand> idr: srsly? *sigh* Writing nir_opt_tex, are we?
crabbedhaloablut has quit [Ping timeout: 480 seconds]
<idr> Well... I just added a few lines to nir_opt_lower_tex.
<idr> But, yeah.
<jekstrand> That probably works. Seems a bit odd, but whatever
<jekstrand> It could also go in constant folding, TBH
<jekstrand> There's a few other whacky cases like that in there
<jekstrand> Like lowering discard_if with an immediate to discard or nothing
<jekstrand> Seems like an ever so slightly better place to put it, maybe.
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Bennett has quit [Remote host closed the connection]
gawin has quit [Read error: No route to host]
tursulin has quit [Read error: Connection reset by peer]
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<ybogdano> Ci will be down until tomorrow morning
<daniels> ybogdano: thanks for the announcement, but please disambiguate it so people know that you're referring to the internal Intel CI and not the upstream Mesa CI
<daniels> the CI that operates on will continue to operate as normal
<ybogdano> my bad sorry
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
<daniels> np!
ybogdano has quit [Ping timeout: 480 seconds]
xlei has quit [Read error: Connection reset by peer]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
dsrt^ has quit [Ping timeout: 480 seconds]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
boistordu_ex has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
boistordu has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
shashanks has joined #dri-devel
agx has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
mbrost__ has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
Duke`` has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
agx has joined #dri-devel
emersion has quit [Read error: Connection reset by peer]
emersion has joined #dri-devel
ddevault has quit [Read error: Connection reset by peer]
bl4ckb0ne has quit [Read error: Connection reset by peer]
bl4ckb0ne has joined #dri-devel
ddevault has joined #dri-devel
itoral has joined #dri-devel
shashanks has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
danvet has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
dliviu has joined #dri-devel
camus1 has joined #dri-devel
nashpa has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
pinchart1 has left #dri-devel [#dri-devel]
pinchartl has joined #dri-devel
Guest5465 is now known as alatiera
tursulin has joined #dri-devel
f11f12 has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
tolszak has joined #dri-devel
<MrCooper> evadot: wayland/ci-templates moved to freedesktop/ci-templates , there have just been breaking changes (which can happen anytime) since
<evadot> MrCooper: yeah, I'll see how to move libdrm to use freedesktop/ci-templates if I can find time
<evadot> MrCooper: then adding FreeBSD should be easy as it's supported there
<MrCooper> cool, can do all of that in a single MR FWIW
<evadot> ok
<evadot> I have a 4 days weekend coming so I might do that then :)
<MrCooper> if you hit any issues, #freedesktop will probably be the better to place for help
<evadot> ok thanks
sdutt_ has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
pnowack has joined #dri-devel
<alatiera> looking at the CI
rgallaispou has joined #dri-devel
itoral has joined #dri-devel
rasterman has joined #dri-devel
demarchi has quit [Remote host closed the connection]
tolszak has quit [Ping timeout: 480 seconds]
<MrCooper> hakzsam: from #freedesktop: alatiera> runner should be back up
<hakzsam> thanks!
TD-Linux has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
pcercuei has quit [Quit: brb]
rando25892 has quit [Quit: No windows for this server]
pcercuei has joined #dri-devel
demarchi has joined #dri-devel
TD-Linux has joined #dri-devel
rando25892 has joined #dri-devel
gawin has joined #dri-devel
<jani> I'm looking at the mode_flags member of struct mipi_dsi_device , and wondering about MIPI_DSI_MODE_LPM flag specifically. is the idea that whoever's doing mipi_dsi_dcs_write() for instance would first set or clear that bit in dsi device? no interface for that, just direct bit set or clear?
<jani> Andrzej Hajda here? or maybe tagr has some idea?`^
<danvet> tzimmermann, sry missed that you added that doc patch without my ack
<danvet> I thought I checked
<danvet> will reply on-list
<tzimmermann> thanks
mclasen has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<dj-death> is there a NIR pass out there that combines temporary variables when for instance var_A is used in the first part of the shader and var_B in another part of the shader
<dj-death> and we could actually just use the same variable all along
<dj-death> I'm asking in the context of ray queries because they need a bunch of storage associated with them
jkrzyszt has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<karolherbst> so, maybe some of you have opinions on this. Using gitlab always comes with the annoying part, that some prefer getting notifications as emails for changes on MRs, but gitlabs notifications are _sooooo_ verbose, I was thinking about, maybe we can make use of CI for that here. So why not having a CI job which diffs the MR changes compared to their base (so rebases won't trigger huge diffs) and just sends out an email if there is such a
<karolherbst> change inside the commits itself?
<karolherbst> is there some bot/whatever doing this already?
<pq> that and diffstat sound nice, but relying on CI to send those out? uh
<karolherbst> yeah...
<karolherbst> better ideas?
<pq> um...
<pq> I guess sending Gitlab patches to Gitlab upstream is out of the question :-p
<karolherbst> we could also have a bot polling.... or maybe a bot polling to check if CI actually sent those out or something.....
<karolherbst> yeah well...
<pq> wonder if Gitlab API would allow an "external" service to implement that
<karolherbst> sure
<karolherbst> mhhh
<gawin> git hooks could be usable, for example if there's ab/rb in commit
<karolherbst> there is also a feed, so if the bot subscribes to the relevant projects... it might work
<pq> gawin, does Gitlab even have git hooks?
<karolherbst> gawin: it's more about catching changes in force pushes to MRs
<karolherbst> pq: good question
<pq> I wouldn't expect Gitlab to have git hooks.
<karolherbst> mhh so yeah.. maybe we could use hooks for it
flacks has quit [Quit: Quitter]
<karolherbst> gawin: ohh, now I got what you meant.. mhhh
<karolherbst> yeah....
camus1 has joined #dri-devel
flacks has joined #dri-devel
<karolherbst> at least all this stuff is hidden behind admin privs
<karolherbst> but
<karolherbst> there are webhooks as well
<karolherbst> this one would be relevant
<karolherbst> so I think I'd prefer using webhooks here
<karolherbst> mhh.. we could even use webhooks for updating patchwork
<karolherbst> so we don't have to put this into CI either
<karolherbst> maybe I could even port my MR pipeline commenting stuff into a webhook
camus has quit [Ping timeout: 480 seconds]
<gawin> not sure how mesa's CI works, but if there was one worker which is building all stuff (and sends binaries to others), then it could be good spot
<gawin> and dead CI kinda equals "there's nothing new worth checking"
<karolherbst> gawin: we don't trigger the CI stuff automatically anymore
<karolherbst> just when assigning to marge
f11f12 has quit [Quit: Leaving]
<gawin> not even building jobs?
<karolherbst> just some really simple checks
aissen has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
aissen has joined #dri-devel
vivijim has joined #dri-devel
itoral has quit [Remote host closed the connection]
<danvet> karolherbst, I have a forever feature request to add git range-diff to gitlab everywhere
<karolherbst> ahh, cool
<danvet> with a rebasing feature branch dev approach it's really the thing you want
<danvet> karolherbst, well emphasis on forever request, no sign of it happening :-(
gawin has quit [Ping timeout: 480 seconds]
<karolherbst> danvet: :/
nchery has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
pcercuei has joined #dri-devel
Company has joined #dri-devel
macromorgan has joined #dri-devel
jewins has joined #dri-devel
iive has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
<zmike> ccr: any chance you've been able to get back to the trace enum thing?
kem has joined #dri-devel
<daniels> karolherbst, gawin: so we do have custom git hooks, and we use those to push to the mirrors, but they need to be fast and reliable since they block pushes
mattrope has joined #dri-devel
Bennett has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<jekstrand> dj-death: Thanks for looking at sync code!
<dj-death> no worries
<dj-death> looks nice
<jekstrand> :D
<jekstrand> I'm really pleased with how it turned out in the end.
<dj-death> I'll do another pass
<jekstrand> I'd like to eventually make the feature detection more automagic but I'm not sure how to do that yet.
<jekstrand> Like just give everyone timeline semaphores and automatically expose VK_EXT_external_fence and friends.
fxkamd has joined #dri-devel
<jekstrand> But, again, not sure how to do that yet.
shashanks has joined #dri-devel
shashank_sharma has joined #dri-devel
shashank_sharma has quit [Remote host closed the connection]
gawin has joined #dri-devel
<ajax> jekstrand: where do we think we are on crocus/amber/!10557/etc
<jekstrand> Fedora 35's been out for a few weeks now. Have you gotten any crocus bugs?
sdutt has quit []
sdutt has joined #dri-devel
<ajax> a few, yes.
<ajax> the word "crocus" apparently appears in exactly four red hat bugs
<ajax> three of them are all which is fixed
<jekstrand> I think airlied is planning to fix that by implementing vappi. 😂
<jekstrand> But, also, sounds like some table somewhere that needs updating. Shouldn't be hard.
<jekstrand> If that's the worst bug you've gotten, that's pretty fantastic, TBH.
<ajax> well. the combination of fedora 35 and 8+ year old laptop is maybe not all that common yet.
* jekstrand pulls out an 11-year-old laptop and updates it.
jkrzyszt has quit [Ping timeout: 480 seconds]
<jekstrand> I guess my feeling says wait until shortly before the 22.0 branch-point and rip i965 out if there's no significant Fedora complaints.
<jekstrand> But maybe I'm being silly and over-cautious
<gawin> gallium nine is huge win for these gpus
<jekstrand> gawin: No one's saying you shouldn't use crocus. :) Just deciding when to burn the bridge behind us.
<gawin> I kinda think maybe it'd best to have one release with crocus as default (most people don't test crocus with software like kwin)
<gawin> though it's too late for 21.3
* ajax wonders how many releases it's been since we started trying to delete classic...
f11f12 has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
<jekstrand> If ajax's amber project works, the distro can still ship i965 if the want.
gawin has quit [Ping timeout: 480 seconds]
<ajax> i should probably run through the exercise of packaging amber for fedora to see where the speed bumps are
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
<ajax> jekstrand: personally i'd say now's as good a time as any, 21.3 is branched and we're probably not getting 21.4
<ajax> which makes 22.0 a nice bright line for when we dropped classic
<jekstrand> I think we agree on which release to plan to drop. It's just a question of if we drop now or give ourselves another month or two to collect potential bug reports.
<jekstrand> Not that I expect that to matter
<jekstrand> Maybe I'm just too chicken to pull the trigger
gawin has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<dcbaker> jekstrand: I'm not :)
* zmike starts chanting DO IT
* dcbaker has some rebasing to do
<gawin> dcbaker: can you check if commit from this MR gonna be picked? thanks
ngcortes has joined #dri-devel
<gawin> nothing important, but maybe you have a bug in script
<dcbaker> gawin: the fixed commit isn't in the 21.2 branch, it doesn't look like eric_engestrom has pulled it for 21.3 yet
<zmike> robclark: can you review when you get a chance
<zmike> pretty simple
<gawin> dcbaker: "the fixed commit isn't in the 21.2 branch" ahh, I overlooked this
<dcbaker> Thanks for mentioning it though, we have found bugs in the scripts before, and I appreciate devs keeping an eye on stable branches :)
gouchi has joined #dri-devel
<karolherbst> so uhm... are force pushes to drm/drm-fixes normal?
<karolherbst> like the tag drm-fixes-2021-10-15 isn't included in any upstream branches anymore
X-Scale` has joined #dri-devel
macromorgan is now known as Guest5528
macromorgan has joined #dri-devel
Guest5528 has quit [Read error: Connection reset by peer]
X-Scale has quit [Ping timeout: 480 seconds]
tarceri_ has joined #dri-devel
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
<eric_engestrom> gawin, dcbaker: 28a6e45a was merged before 21.3 was branched, so there's no need to cherry-pick anything :)
<evadot> MrCooper: so that wasn't that hard after all :
<eric_engestrom> evadot: woohoo for freebsd ci \o/
X-Scale has joined #dri-devel
<evadot> next step is mesa :)
rgallaispou has quit [Read error: Connection reset by peer]
gouchi has quit [Remote host closed the connection]
<eric_engestrom> looking forward to that :)
X-Scale` has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
flacks has quit [Quit: Quitter]
<airlied> karolherbst: often i screw up gpg and rerunning dim generates.another tag maybe
<airlied> but that should show up as merged
<karolherbst> airlied: yeah... but something changed so I am curious
<karolherbst> and I know that tag was on the drm-fixes branch
<karolherbst> same for drm-fixes-2021-10-15, drm-fixes-2021-10-08 is fine
<karolherbst> ehh
<karolherbst> airlied: ohhh
<karolherbst> there is actually drm-fixes-2021-10-15-1 ..
<karolherbst> airlied: anyway.. not sure what dim does, but the branch was forced pushed as far as I can tell
<airlied> yeah i have force pushed it in the past for various screw ups
<karolherbst> okay... I assumed we don't do that (tm) :p
<airlied> we try not to for the misc branches
flacks has joined #dri-devel
<karolherbst> okay
<airlied> but sometimes Linus will push back and ive no choice
<karolherbst> ahh...
<airlied> and sometimes ill screw up
<karolherbst> while we are at it.. I actually did a mistake as I forgot to fix a commit message on drm-misc-fixes...
<karolherbst> could that also cause issues or shouldn't I worry about those kind of mistakes?
<zmike> jenatali: I suspect it would help you too if only you could use it :D
<jenatali> zmike: Hm? Was there a reason I couldn't use it?
<zmike> jenatali: yes, #5277
<jenatali> Oh right :P
<airlied> karolherbst: so in the drm-fixes-2021-10-15 case I decided the vc4 fixes were too much for Linus at that stage
<jenatali> I can hook up the caps trivially, I just can't remove the fallback to handle unsupported prims getting into the driver yet until all trifans/quads go through vbuf/cso
<airlied> so unpulled the misc fixes branch and cherry-pick over the ones I wanted
<karolherbst> ahhh
<zmike> hooking up the caps will break your edge flag handling though
<jenatali> Oh right :(
<zmike> like I said
<jenatali> Not sure how much I care, that might be worth taking the regression for now
<zmike> it's going into mesa/st at some point :)
<zmike> as for the other state trackers I suppose it's up to you to decide how much you're interested in them
<jenatali> I think I'm close to actually having time to look at some more of this stuff soon - I'm looking at Minecraft perf and these index buffer readbacks for primconvert are killing us
camus has joined #dri-devel
<zmike> I had a minecraft ticket I was looking at once upon a time
* zmike tries to remember what happened to it
<jenatali> Dunno if they're using dlists, so I dunno if your change specifically would help, but if they are it'd be nice
<zmike> the dlist change there doesn't hit all old-style vertex cases
<zmike> I only did it because I'm implementing vertex state draws
<zmike> which use this
<jenatali> I see
<zmike> probably for actual index buffers we'd want something else
<zmike> not sure what though
<jenatali> Yeah I need some kind of primconvert cache I think
<zmike> not sure how that'd work?
<zmike> it'd still have to read the index buffer back to know what to look up
<zmike> and that's the slow part
<jenatali> Not sure either. But I'm seeing index buffer uploads that we then have to read back and that is super slow. If we could just remember what we uploaded it'd save us a ton of work
<jenatali> All because they're 1-byte indices that we don't support :(
<airlied> is the readback once per index buffer or repeated?
camus1 has quit [Ping timeout: 480 seconds]
<jenatali> Pretty sure it's repeated...
<jenatali> I got far enough to see that's a problem but haven't gotten back to it to figure out how to fix it yet
<zmike> is it being uploaded from explicit vertex calls or from a vertex buffer?
<zmike> if it's the former then there's more places in mesa/main where vertex data is handled that can do pre-conversions like my MR
<zmike> if it's the latter.... 🤔
<airlied> ajax, jekstrand : oh that va name bug, have to track that down, might be in the X server
<anholt_> lots of this fail again today
<anholt_> jenatali: ?
<jenatali> anholt_: Was reported in #freedesktop and I think it's already fixed
<anholt_> do we know what's been up with it?
<jenatali> I don't, at least
<HdkR> Wait, something actually is using 1-byte indices?
<jenatali> HdkR: I've seen at least 2 apps so far. One of them reached out to me directly and I told them to stop. The other is Minecraft :P
<HdkR> Wow.
<airlied> Kayden: you remember how iris dealt with the va library name?
pnowack has quit [Quit: pnowack]
nchery is now known as Guest5538
nchery has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
Guest5538 has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
pnowack has joined #dri-devel
<Kayden> airlied: nope, not really
<Kayden> I remember some conversations about iris totally breaking libva and other people not believing that
Bennett has quit [Remote host closed the connection]
<airlied> ah libva has a driver_name_map
<mareko> zmike: FYI, you can bind vertex buffers as the vulkan equivalent of TBOs or image buffers, and do additional format conversion in the shader after loads
<mareko> also 1byte indices could be emulated in the same way and just modify VertexID
<zmike> this is true, but tbos are kind of a pain to work with given the validity requirements
<mareko> TBOs have an implicit stride, you'd need something where you can set your own stride
<zmike> true
<zmike> still not something I'm urgently looking into until I have a real case that's hitting it
<zmike> otherwise I'll probably just wait until I can use task+mesh shaders or something
gawin has joined #dri-devel
<mareko> mesh shaders will raise the hw requirements to RDNA2, which is not great, while vertex shaders could do the same thing
<zmike> sure, but I'm also just one person, and there's more urgent things I need to do for now :)
<airlied> zmike: sounds like you need to be running minecraft :-P
<zmike> I did a few months ago
<zmike> no problems here
<Sachiel> time to implement task/mesh shaders with redstone
* zmike checks stackoverflow
jewins1 has joined #dri-devel
<jenatali> It works, it's just slower than necessary because of primconvert, at least for me
<jenatali> Maybe some other features will fix it, I dunno
<karolherbst> ohhh, Gsoc was opened up to all adults :O
jewins has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<Kayden> airlied: hmm...yeah...we might need to update that. cue decisions about what order to probe things in, too...
<Kayden> for the X server I made it use EGL_MESA_query_driver instead of having its own map, but I doubt libva can do that as it probably doesn't egl at all
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<airlied> Kayden: once we have iris/crocus vaapi it'll all be fine :-P
<cmarcelo> anholt_: added another attribute to the serialization fix, mind acking? ->
nchery has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
<mareko> jenatali: converting ubyte indices to ushort doesn't need primconvert, see how we use util_shorten_ubyte_elts_to_userptr
<jenatali> mareko: Still requires a pipe_buffer_map though. Same problem regardless which code does it
<mareko> ideally you would know that the index buffer is idle or used for read only, so that you don't have synchronize with the GPU
<jenatali> Yeah I think the problem we're seeing is that there's a non-directly-mappable index buffer, so we have a GPU write to it for the indices, and then we need to read it back which requires re-syncing with the GPU to wait for the write to be done
<mareko> how about primconvert as a compute shader
<jenatali> I'm onboard :)
<jenatali> Except I haven't written the compute stack yet for our gallium driver yet
<mareko> we also don't have the compute shader
<jenatali> Psh details :P
<jekstrand> A compute shader for converting ubyte to ushort? I can type the nir_builder for you in 20 minutes.
<jekstrand> I won't do anything but compile-test it of course, and only if you're lucky. :-P
<jenatali> Yeah that one would be trivial, the rest of primconvert would be harder, but also immensely useful
<mareko> some GPUs have ubyte indices like AMD since Volcanic Islands
<jenatali> Yeah. We'd talked about adding it (back?) to D3D when we looked at adding our gallium backend, but it seemed simple enough to emulate. And it is, it's just these perf gotchas
sdutt has quit []
sdutt has joined #dri-devel
<zmike> jekstrand: I'm gonna take you up on that next year after my vacation :P
JohnnyonFlame has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<jekstrand> zmike: :P
<jekstrand> We've always had UBYTE
ceyusa has quit [Remote host closed the connection]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<robclark> jenatali: it would be nice if, once we start detecting primconvert re-writing index buffers, we passed some flag to the driver on resource allocation for index buffers that CPU readback is likely.. minecraft (quad emulation with readback from writecombine bo's isn't great.. a hint that we should switch to cached coherent buffers instead would fix that)
ceyusa has joined #dri-devel
<anholt_> I think the compute shader solution is the real right way to go, though
<jenatali> robclark: Yeah. Not sure we can know at allocation time that it's going to be an index buffer that's used with an unsupported index format / prim type though
<jenatali> Agreed compute is probably the right long-term solution
<jekstrand> The tricky thing with a CS solution is that you need to be careful that switching between 3D and compute doesn't cause silly stalls.
<bnieuwenhuizen> DispatchMultiIndirect at the start of your renderpass :)
<jenatali> Those stalls would still be way better than going all the way back to the CPU
<jekstrand> If you can batch a bunch of rewrites up into back-to-back compute calls with no barriers between them or, better yet, one compute call, and then do a bunch of drawing, that's best.
<jekstrand> jenatali: Oh, for sure.
<HdkR> Big brain move, expose byte indices in D3D
<jekstrand> All the D3D HW can do them....
<jekstrand> Or most, anyway
<jenatali> Yeah...
<jekstrand> Intel can since about forever
<bnieuwenhuizen> AMD only since 2016 or so
pcercuei has quit [Quit: dodo]
<bnieuwenhuizen> er, 2014*
<jekstrand> bnieuwenhuizen: And since those are the only GPUs people can actually afford these days...
<bnieuwenhuizen> jekstrand: you'd be surprised. Even your run of the mill Polaris based card from 2016 is marked up 100% or so these days
<jekstrand> I was looking at CPUs this week, thinking of building a new desktop (mine's a HSW) and dang....
<jekstrand> If I want something competent, it's looking like a $5k project.
<airlied> just reuse your old gpu :-P
<bnieuwenhuizen> how competent? I hear Intel released some pretty cheap CPUs with lots of cores last week
<jekstrand> bnieuwenhuizen: Yeah, but half those cores are rubbish. :P
<bnieuwenhuizen> IIRc they were decent at compilation, but would need to find the benchmarkj
<robclark> jenatali: if game was using quads on frame N, it is probably going to use them on frame N+1.. although I guess maybe you want to consider what percentage of draws are getting re-written
<jekstrand> I can get a 18-core i9 through the employee purchase program for reasonable.
<bnieuwenhuizen> oh well, not much sense harping CPUs then
<jenatali> robclark: Yeah. Or maybe just once it has to be primconverted once, always cache new uploads for that buffer so they can be converted without having to do readback
<jenatali> Assuming the index buffer's not being generated via compute or something like that
<bnieuwenhuizen> can you get a GPU for a reasonable price with the same price (maybe an Arc GPU even)
<bnieuwenhuizen> with the same program*
<jekstrand> bnieuwenhuizen: Yeah, no. They're not shipping publicly.
<jekstrand> bnieuwenhuizen: Yes, I can get an 18-core i9 but if you are willing to spend stupid money, threadrippers go up to a lot of cores. :)
<bnieuwenhuizen> jekstrand: if you're dealing haswell I assume you can wait those few more months
<jekstrand> heh
<bnieuwenhuizen> yeah but you'd be paying through the nose for those cores
<jekstrand> It's true
<jekstrand> Best bang/$ is probably employee purchase program.
<jekstrand> I should figure out what they want for a motherboard to go with it.
<bnieuwenhuizen> also threadripper is getting old :( Zen2 still, no zen3 a year after release and no sight of any zen3 threadrippers anytime soon
<jekstrand> :-/
<jekstrand> The i9s aren't exactly new tech either.
<bnieuwenhuizen> before you know it you can't get GPU limited anymore because the singlethread perf sucks
<bnieuwenhuizen> though I guess I just need to finish raytracing to deal with that :P
pcercuei has joined #dri-devel
<jekstrand> heh