ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
sdutt has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<alyssa> airlied: I hear splitting up headers to improve build time is all the rage these days :-p
<alyssa> Maybe that's what jekstrand will be doing at his new job at Shopify
<airlied> alyssa: yeah just trying to keep up with cool kids
<alyssa> I hear the cool kids are writing drivers for the M1
<alyssa> maybe you should try that :p
<airlied> though I did started this initially because every change to mtypes.h was pissing me off rebuilding all of glsl :-P
<airlied> made refactoring the state tracker on my laptop take a lot of time :-P
<alyssa> ah yes that's what the M1 is for ;-P
<daniels> alyssa: the M1 does have PCIE
<alyssa> technically
<alyssa> Corellium said at Black Hat it's too limited for discrete GPUs, though dunno if they're right
<daniels> oh :(
LexSfX has quit []
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
pnowack has quit [Quit: pnowack]
<jekstrand> airlied: Just buy more cores. Problem solved. :-P
<anholt> jekstrand: unfortunately, mesa actually kinda sucks at just using more cores.
<anholt> between intel_perf and gtest tests, we've got some really long compiles.
<alyssa> isn't that embarassingly parallelizable?
off^ has quit [Remote host closed the connection]
<airlied> jekstrand: for my laptop, I think alyssa is right, get an M1 :-P
<airlied> I think getting gl.h out of nir.h though is a worthy goal
<airlied> it really has very little use in there
<alyssa> nir.h recompiles suck hard.
iive has quit []
<robclark> splitting up nir.h (like say moving all the nir pass prototypes and related structs to their own header) wouldn't be a horrible idea
<jekstrand> airlied: Yeah, nir.h should pull in very little if we're doing our jobs right
<jekstrand> Sadly, I think it pulls in gl.h, mtypes.h, and others.
<jekstrand> 'cause reasons
<alyssa> jekstrand: aren't you supposed to be on vacation
<jekstrand> alyssa: I suck at vacation. This is well-established. :-P
<alyssa> before your first day at the Canadian Digital Service
qyliss_ has quit []
<airlied> jekstrand: I've mostly got gl.h out of it, but badly
qyliss has joined #dri-devel
<jekstrand> Uh oh...
<jekstrand> airlied: What does NIR use from gl.h?!?
<airlied> jekstrand: it mostly proxies in the gl.h for other compile units :-P
<jekstrand> oh...
<airlied> is the bad version
<cworth> That's usually how it happens with code bases, of course...
<airlied> since it just includes gl.h anywhere that touches tess or gs primitive shader info
<airlied> but I think if I make shader_info enums for those instead of using GL I can clean it up nicer
<airlied> the nir_types.h is also necessary
<airlied> change
<alyssa> in general, the fact that we have GL_* enums in our Vulkan drivers is terrifying.
<airlied> yes and this will fix that hopefilly
<Kayden> oh, the types
<Kayden> definitely a fan of having shader_enums.h add enums for anything we're using from GL in types or nir/
<Kayden> I think it's mostly builtin_type_macros.h that's at fault
<Kayden> otherwise there's a couple instances of GL_CCW, GL_ISOLINES, etc that are easy enough to replace with an enum.
join_subline has joined #dri-devel
<Kayden> I certainly don't think it's terrifying, it's just some mundane cleanup
<airlied> yeah I'm just working on the tess prim first now
libv_ has quit [Ping timeout: 480 seconds]
libv has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<alyssa> Kayden: i'm terrified of all code,
<alyssa> especially code written by other people,
<alyssa> and especially code written by me.
<anholt> take the ajax strategy of just delete code instead of writing it.
<jekstrand> alyssa: Yup, that's all code. :)
ybogdano has quit [Ping timeout: 480 seconds]
<anholt> jekstrand: well, there's also code not written by people. https://copilot.github.com/
<alyssa> that terrifies me most
<jekstrand> :D
<alyssa> admittedly anholt's code is the least scary in Mesa
<alyssa> except the intel pieces
<alyssa> even anholt can't make the intel brw compiler not scary
<jekstrand> alyssa: What about my code? :P
<anholt> which is why I'm importing some brw compiler into ntt /o\
<alyssa> jekstrand: Scarier than anholt's but much less scary than average
<alyssa> Kayden too
<alyssa> jekstrand: Look you know how much I look up to you but nir_from_ssa is absolutely terrifying.
<jekstrand> Glad to know where I stand.
<jekstrand> alyssa: Not nearly as terrifying as nir_algebraic.py :D
<graphitemaster> gcc's reload.c is my goto for how bad code can become when I come across bad code at work and need a reminder that it isn't all that bad
<graphitemaster> it's about perspective
<alyssa> this I gotta see
<anholt> https://gcc.gnu.org/wiki/reload is off to a great start
<dcbaker> But Can anyone beat mattst88’s ternary?
<mattst88> oh god, what did I do?
<graphitemaster> dcbaker, I might have two functions I wrote for ternary cake https://github.com/BuckeyeSoftware/foundation/blob/master/bes/foundation/string.c#L532-L581
<jekstrand> graphitemaster: Oh, that's impressive. :)
<dcbaker> You wrote a 5? Level deep ternary once
<jekstrand> That's not too bad if you structure it right
<alyssa> "Reload is the GCC equivalent of Satan"
<mattst88> dcbaker: oh yeah, but as I learned that's... typical in C++ :|
<graphitemaster> I have a tendency to use ternary more often than if if I can because conditional moves seem to happen more when I do.
<Kayden> reading through ilo was always a bit tricky because it wasn't written by anholt. I am used to reading anholt's code :)
<bnieuwenhuizen> f you keep it to chaining and indent align properly long ternary chains aren't too bad
<mattst88> bnieuwenhuizen: exactly
<mattst88> daniels: next image should be someone tossing a computer into a ravine and giving up
<alyssa> When I was younger I wanted to minimize LOC at all costs and liked ternary tricks
<alyssa> I'm starting to see the value in more verbose, more obvious code.
<alyssa> ...starting to
<Kayden> when statement-expression makes your code -more- readable, functions might be your friend :)
<bnieuwenhuizen> I do tend to do more ternary in verilog though. Very tempting with assign somehow
<alyssa> Kayden: Yep.
<daniels> alyssa: when you realise 'that's very clever' is not usually a compliment in code review?
<idr> Frequently the most terrifying thing is to look back at code that you wrote many years ago but remember being very proud of.
<daniels> mattst88: ideally on fire
<alyssa> daniels: jokes on me nobody reviews my code anymore
<idr> "WTF does this even do?"
<alyssa> I guess jekstrand might change that...
<mattst88> daniels: hahaha
<airlied> it's all fun and games until someone use primitive mode in r600
<bnieuwenhuizen> airlied: primitive mode?
<alyssa> idr: that would be the scheduler and register allocator for the Midgard compiler
<jekstrand> alyssa: Maybe. We'll see. More likely, I just throw you code to review.
<airlied> bnieuwenhuizen: tess primitive mode TRIANGLES/QUADS/ISOLINES
<Kayden> mattst88: maybe they threw it in here, https://c.tenor.com/wG600D2TwHgAAAAd/dumpster-fire-flood.gif
<alyssa> jekstrand: I'm good with that too
<daniels> Kayden: :D
<idr> alyssa: Make note of that SHA and come back to it at this time in 2032.
<mattst88> Kayden: I love that so much
<graphitemaster> I have it on good authority that graphics drivers are really hard to write so you should just be allowed to do gnarly things for consistency reasons
<jekstrand> alyssa: Or just wire up enough OpenCL to make panfrost blow up and throw you bug reports. :P
<graphitemaster> Code review, pftt.
<alyssa> jekstrand: I have so little time >.>
<alyssa> Like I haven't logged a single minute of panfrost this week..
<alyssa> ("And yet you had time for dozens of asahi commits?" "shutup")
<Kayden> OpenCL kernel that generate GPU commands to run OpenCL kernels are always a bit scary
<graphitemaster> Sometimes you just got to treat yo self to writing really bad code, keeps you young.
<Kayden> "we heard you liked graphics drivers"
<idr> Lol
<bnieuwenhuizen> Kayden: I have a recent VK_NV_device_generated_commands implementation lying around . Gets scarily close
<Kayden> exactly
<bnieuwenhuizen> the extra scary part is doing it all in nir_builder
<alyssa> nir_builder gets really unwieldy for shaders with >50 instructions
<mattst88> someone implemented a RISC-V emulator in a fragment shader: https://blog.pimaker.at/texts/rvc1/
<graphitemaster> You joke but I won't be content until entire video games are written in compute shaders.
<bnieuwenhuizen> alyssa: you'll love the ~1000 lines of nir in src/amd/vulkan/radv_pipeline_rt.c
<alyssa> graphitemaster: why not in fragment shaders?
<alyssa> shadertoy flappybird has entered the chat
<graphitemaster> No CPU code at all except to upload some stuff, late latch input on the GPU with some persistenty mapped MMIO for input.
<graphitemaster> Poll the keyboard bitmask and mouse state in each invocation XD
<graphitemaster> Input latency, what's that
<alyssa> bnieuwenhuizen: src/panfrost/lib/pan_indirect_draw.c
<graphitemaster> Bring back immediate rendering, no need for vsync, everyone has variable refresh rate displays in my reality.
<alyssa> bnieuwenhuizen: you remind me i'm supposed to be writing a ray tracer for class.. um
<bnieuwenhuizen> implement vulkan raytracing while at it?
<airlied> alyssa: just write llvmpipe impl :-P
<graphitemaster> alyssa, I would concede to fragment shader everything if and only if, GPU apis allowed for 3D fragments, imagine if you will an FBO with 3D texture attachments right, and then a draw call actually worked on every slice of that like a 3D compute shader invocation, but no geometry shader needed - the vertex shader would get a gl_SliceID and have to emit a primitives for every layer, the input assembly would have a new attrib divisor
<graphitemaster> for specifying the distance between attributes for the next primitive on that layer, and gl_FragCoord.xyz would literally be the sample index of the 3D volume texture. Give that and we can kill compute
<graphitemaster> 2D rasterization is so last century
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
<jekstrand> zmike: The big triangle, eh? I suppose the lizard men are inside it?
ramaling has quit [Read error: Connection reset by peer]
ramaling has joined #dri-devel
<graphitemaster> jekstrand, what's the lore behind your employment - it's very strange I see mention of it here, phronoix and some other places (blog sites *heh*) so frequently
<dcbaker> Can we replace rumors of Jason’s employment with his origin now?
<graphitemaster> It's strange it has escaped the confines into public perception - at this rate he'll be in the next Marvel movie.
<airlied> you can see him in iron man 2 just behind elon musk
<dcbaker> He was born from a compute shader that became sentient
<Sachiel> that's why he can't take vacations? No preemption?
<jenatali> airlied: If you do refactor the tess stuff, I'd love a tag in the MR, it'll blow up my in-progress tess MR
Company has quit [Quit: Leaving]
<airlied> jenatali: just pushed the initial MR to see how it explodes
<airlied> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14605 for anyone following along at home
<jenatali> Thanks!
<alanc> clearly he should have waited until after the Microsoft/Activison (Macrovision?) deal was announced so that someone could explain how his new job was tied into that
<jenatali> Spoiler, it's not :)
<airlied> alanc: they held off announcing that deal until the job rumour was settled
<jekstrand> jenatali: Come on. You can get on the rumor train too! Everyone's doing it.
<jenatali> Oh, for some reason I thought that was directed at me. Nevermind, carry on
<alyssa> jekstrand: really wanted to work on a Vulkan port of Viva Piñata
<graphitemaster> My theory is he's going to work at Pixar
<graphitemaster> They've been snatching up driver devs like crazy recently
<jekstrand> Pixar is welcome to contract with Collabora.
camus1 has joined #dri-devel
<alyssa> jekstrand: Hmm... but what if Collabora hired Pixar? 🙃
camus has quit [Ping timeout: 480 seconds]
<jekstrand> alyssa: Somehow, I don't think collabora's piggy banks are quite that large...
<alyssa> 🐷
bbrezillon has quit [Read error: Connection reset by peer]
mripard has quit [Write error: connection closed]
co1umbarius has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
columbarius has quit [Ping timeout: 480 seconds]
<graphitemaster> Valve is also a pretty safe guess
<graphitemaster> Work on stuff to make the Steam Deck actually usable.
<graphitemaster> But I feel like someone already made that guess
<graphitemaster> It's too easy
<alyssa> maybe he's writing a Metal-on-Vulkan layer for Valve
<alyssa> due to the proliferation of macOS-only AAA titles
<daniels> alanc: Macrovision :D
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
<graphitemaster> We have an obsession with API-on-API translation layers - have we become Ouroboros yet? NO ONE BUY THAT DOMAIN IM GETTING IT NOW
<graphitemaster> areweouroborosyet.com
<dcbaker> daniels: there’s a company I haven’t thought of in a long time
gawin has quit [Ping timeout: 480 seconds]
<jekstrand> Maybe I've been hired as the CTO of Atari to help revive it...
<dcbaker> I guess everyone needs to joust windmills at least once in their life
<imirkin> to make it 1980 again through science or magic?
<graphitemaster> I got it, IBM is getting into the dedicated GPU business and hired exactly one graphics driver developer.
<dcbaker> It worked for Broadcom…
<jekstrand> I know better than to work for IBM...
<jessica_24> hey vsyrjala: , I had a question on my kms_cursor_legacy patch (https://patchwork.freedesktop.org/patch/466272/?series=97875&rev=1), I saw your comment about the nonblocking flip, but I was wondering where is it guaranteed in the test that the nonblocking flip will always be queued after the cursor ioctl. Is it not possible for the flip to finish and be queued before the cursor ioctl starts?
<graphitemaster> I imagine working for IBM during the pandemic involves wearing a suit and tie at home during Zoom meetings.
<graphitemaster> Like that's the kind of culture image I have of them.
<graphitemaster> Everyone that works there can double as a funeral director.
<imirkin> graphitemaster: but no pants...
<graphitemaster> How many funeral directors do you know who don't wear pants?
<imirkin> i meant for the zoom meetings
<imirkin> coat + tie
<graphitemaster> Maybe, it would be risky though. What if they require proof of pants
<graphitemaster> Like before every meeting you have to twirl for the project manager
<jekstrand> Or maybe they require you to wear special tracking pants and have a device in your computer that verifies that you have one such pair of paints on.
<imirkin> then they get to see more than they bargained for...
<graphitemaster> We're dangerously close to developing a new kink.
<graphitemaster> But also dystopia.
alexeymin_ has left #dri-devel [#dri-devel]
<graphitemaster> This is wild to me
<graphitemaster> Like if this is RDNA 2 but in a mobile form factor does that mean this is a TBDR RDNA 2?
<graphitemaster> Otherwise are these things just going to come filled to the brim with video memory?
<graphitemaster> If they're doing TBDR then I'd no longer call this RDNA 2, that's such an architectural change >_>
<jekstrand> It'll be interesting to see how it performs when paired with shit mobile memory bandwidth.
<graphitemaster> Maybe it'll be HBM memory XD
<jekstrand> In a phone? That'll be the day.
<jekstrand> LBM, more like.
<bnieuwenhuizen> jekstrand: question is whether they added any of that infinity cache
<jekstrand> epsilon cache. :P
<bnieuwenhuizen> or L3 as you might call it
<graphitemaster> I wonder how the hell it even works, the AMDGPU Linux driver stack definitely does not function on an ARM system
<bnieuwenhuizen> I think SLCs are pretty common on phones now, so proably they have some decent cache?
<bnieuwenhuizen> graphitemaster: AFAIU my understanding is that it works on ARM systems in principle, there were just a few common things on ARM platforms it has trouble with? (e.g. I've heard stuff like platforms that only do 32-bit access over PCIE)
<bnieuwenhuizen> I'd believe that can be fixed if you cooperate on the HW
<jekstrand> Maybe they're running windows on it?
<bnieuwenhuizen> is there a recent incarnation of anything mobile windows?
<jekstrand> There's ARM windows with qcom
<bnieuwenhuizen> oh right, weren't there rumors about some exclusivity thing with qcom though? Also that isn't that phone-suitable wrt UI I think?
<jekstrand> Or maybe they've fixed amdkfd internally and not sent the patches yet?
<jekstrand> Or maybe they've fixed it by adding another PAL (-:
<airlied> I'm guessing they fixed the hw to work properly :-P
<graphitemaster> You'd have to fix the drivers regardless because there's no way in hell this is standard RDNA 2
<bnieuwenhuizen> actually kind of curious, have no idea at all what the driver stack is or how close the things are to "upstream" navi2 HW
<HdkR> bnieuwenhuizen: Just skip the PCIe bus entirely. Just use the AMBA/AXI bus which can be coherent :P
jewins has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<alyssa> "can"
boistordu_ex has joined #dri-devel
<graphitemaster> coherency is just a state of mind
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
<airlied> jekstrand, Kayden : 14605 now drops gl.h from brw and nir
<jekstrand> \o/
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
heat has quit [Remote host closed the connection]
aravind has joined #dri-devel
heat has joined #dri-devel
<robclark> bnieuwenhuizen: qcom stuff has had LLCC (system cache) for a long time.. not really enough to compensate for not being a tiler (other than for significantly more advanced workloads which don't benefit as much from being a tiler, compared to stuff in play store).. and windows/qcom exclusive rumors where about 8c[x] (doesn't apply to 7c) and future things which might have random marketing dept derived names
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
LexSfX has joined #dri-devel
<ishitatsuyuki> In the previous attempt I just unrolled it for all possible x but I wonder if there's a good way... https://gitlab.freedesktop.org/ishitatsuyuki/mesa/-/blob/acominer/src/compiler/nir/nir_opt_algebraic.py#L1181
<ishitatsuyuki> What's a good way to code a algebraic opt such that it can match (32 - x) wrt to some x in a way that also applies when x is constant?
<ishitatsuyuki> I'm also thinking to make this kind of opt for bitselect ((src0 & src1) | (~src0 & src2)) where unrolling for src0 is impossible due to larger number of permutations
<mattst88> does some AMD gfx have an instruction for fshr?
<imirkin> define 'fshr'?
<imirkin> is it just div-by-power-of-2?
<mattst88> it's an opcode in the link he pasted -- it looks like it takes operands 'a' and 'b' and ORs them together after shifting them in opposite directions by 'c' bits
<imirkin> oh. i thought it was an unrelated question.
<imirkin> sounds like bitfieldInsert
<ishitatsuyuki> it's named after the an instrinsic with the same name in CUDA, but it's implemented on AMD as well (technically it's fshl for AMD, but it's trivial to reverse the direction)
<ishitatsuyuki> it's not bfi
<ishitatsuyuki> it's v_bitalign
<imirkin> which nvidia op does it relate to?
<imirkin> (if it's in cuda...)
<ishitatsuyuki> fshr
<ishitatsuyuki> funnel shift fwiw
<imirkin> oh. duh. SHR.F
<imirkin> didn't make the connection. sorry.
<ishitatsuyuki> yeah apparently fshr was the llvm naming, my bad
<imirkin> it's used for 64-bit int shifts with a 32-bit alu op
<imirkin> there's a SHL.F and SHR.F
<mattst88> neat instruction
<ishitatsuyuki> is it... neat? pretty sure the only use is to do the rotate operation in hash functions
<imirkin> and i flubbed the name. SHF.R / SHF.L btw
<imirkin> this is where we do the work to implement the shifts *without* those
<imirkin> heh
<mattst88> ishitatsuyuki: I think your *[... for range(1, 32)] comprehension is pretty good. it's unfortunate we don't have something better
<ishitatsuyuki> I see
<mattst88> we've had similar questions about other shift operations in the past
<mattst88> maybe we should add a NIR operation that is only emitted by optimizations, that just does log2(x)
<mattst88> we could apply it in this case and let constant evaluation/folding clean everything up
<mattst88> would be a lot better than 32 separate rules
mclasen has quit [Ping timeout: 480 seconds]
aravind has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
aravind has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
tlwoerner has joined #dri-devel
Hi-Angel has joined #dri-devel
Duke`` has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
mszyprow has joined #dri-devel
lemonzest has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
tlwoerner has joined #dri-devel
itoral has joined #dri-devel
jagan_ has quit [Quit: Page closed]
mattrope has quit [Read error: Connection reset by peer]
fxkamd has quit []
Duke`` has quit [Ping timeout: 480 seconds]
tango_ has quit [Read error: Connection reset by peer]
tzimmermann has joined #dri-devel
ahajda has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mlankhorst has joined #dri-devel
<airlied> jenatali: stripped out gl.h from some places seems to cause windows.h conflicts elsewhere
<airlied> I expect we have some paths that read windows.h without lean/mean turned on
<airlied> found one in memstream.h will throw at cI
MajorBiscuit has joined #dri-devel
frieder has joined #dri-devel
mlankhorst has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
danvet has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
frytaped has joined #dri-devel
Major_Biscuit has joined #dri-devel
tursulin has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
ahajda has quit [Remote host closed the connection]
heat has quit [Ping timeout: 480 seconds]
<tzimmermann> Lyude, danvet, i have two trivial fixes for the recent displayport patchset. please review if possible.
frytaped has quit [Quit: frytaped]
<javierm> tzimmermann: both patches look good to me and are trivial enough that I could review
itoral has quit [Remote host closed the connection]
<tzimmermann> javierm, please do
itoral has joined #dri-devel
<tzimmermann> they fix building
<javierm> tzimmermann: yes, I already did. And for that reason, in case you want to push to drm-misc ASAP since the culprit is already there
pcercuei has joined #dri-devel
sagar__ has quit [Remote host closed the connection]
sagar__ has joined #dri-devel
<tzimmermann> javierm, thanks a lot! i'll push them in a bit
itoral has quit [Remote host closed the connection]
ramaling has quit [coherence.oftc.net nucleus.oftc.net]
ishitatsuyuki has quit [coherence.oftc.net nucleus.oftc.net]
ishitatsuyuki has joined #dri-devel
pnowack has joined #dri-devel
ramaling has joined #dri-devel
aissen has quit [Ping timeout: 480 seconds]
whald has joined #dri-devel
mvlad has joined #dri-devel
rgallaispou has joined #dri-devel
rgallaispou has quit []
rgallaispou has joined #dri-devel
JohnnyonFlame has joined #dri-devel
rasterman has joined #dri-devel
rasterman has quit []
rasterman has joined #dri-devel
whald has quit []
hansg has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
sagar__ has quit [Remote host closed the connection]
sagar__ has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
ahajda has joined #dri-devel
mclasen has joined #dri-devel
itoral has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
itoral has quit [Remote host closed the connection]
linearcannon has quit [Read error: No route to host]
rgallaispou has quit [Read error: Connection reset by peer]
linearcannon has joined #dri-devel
rgallaispou has joined #dri-devel
thellstrom has joined #dri-devel
thellstrom1 has quit [Read error: Connection reset by peer]
thellstrom has quit []
thellstrom has joined #dri-devel
flacks has quit [Quit: Quitter]
thellstrom has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
mi6x3m has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
<mi6x3m> hey ajax, care to help me some more? I'm trying to understand how __DriverAPIRec with stuff like InitScreen and CreateContext is loaded from the _dri.so object
sdutt has joined #dri-devel
<mi6x3m> i can't find a dlsym for the driver api stuff
<mi6x3m> only some externs pointing there
<mi6x3m> there is also 'globalDriverAPI' which is never loaded anywhere
kts has joined #dri-devel
<jfalempe> tzimmermann, I don't have the CR+LF on my local patch for mgag200, I'm wondering where it comes from. I used git send-email to avoid this kind of issue.
<tzimmermann> jfalempe, never mind. maybe it's my email client. i think i had a similar issue before. i'll merge your patch then
<jfalempe> ok thanks ;)
ezequielg_ has quit []
ezequielg has joined #dri-devel
jewins has joined #dri-devel
V_ is now known as V
<rgallaispou> Hello everyone
<rgallaispou> I had some questions regarding the CRC feature.
<rgallaispou> Does it need to be reported to DRM after each vblank irq or can it be when the screen frame changes ?
mattrope has joined #dri-devel
<rgallaispou> In the case where it is at each vblank, is it supposed to stop being reported when the disable_vblank is called ? Is it allowed to prevent the vblank to stop when the CRC is activated since it is only mostly a test feature ?
alyssa has left #dri-devel [#dri-devel]
kts has quit [Quit: Konversation terminated!]
gawin has joined #dri-devel
Danct12 has joined #dri-devel
rgallaispou has quit [Quit: Leaving.]
rgallaispou has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
devilhorns has joined #dri-devel
mi6x3m has quit [Quit: Leaving]
hch12907 has joined #dri-devel
pH5_ is now known as pH5
hansg has quit [Quit: Leaving]
mszyprow has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
<ccr> zmike, will Copper .. err .. Kopper developers be now called (Keystone) Kops? :D
<zmike> :D
* ccr gets the pies ready.
Duke`` has joined #dri-devel
Haaninjo has joined #dri-devel
<javierm> tzimmermann, zackr: do you have any idea why Thomas's patch doesn't work? Reading kernel/resource.c and drivers/pci/pci.c I can't see why it would fail...
<tzimmermann> javierm, me neither
jekstrand has quit [Ping timeout: 480 seconds]
<tzimmermann> maybe because the BOOTFB entry is still there and has a resource attached. the vmwgfx resource is larger then BOOTFB. that might affect it as well
<tzimmermann> javierm, sorry, i have to leave now
tzimmermann has quit [Quit: Leaving]
macromorgan is now known as Guest1049
macromorgan has joined #dri-devel
Guest1049 has quit [Read error: Connection reset by peer]
mlankhorst has quit [Ping timeout: 480 seconds]
jekstrand has joined #dri-devel
mlankhorst has joined #dri-devel
nchery has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
Bennett has joined #dri-devel
frieder has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
gouchi has joined #dri-devel
ella-0 has joined #dri-devel
kts has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
<ccr> zmike, out of curiosity, have you ran into any funny issues with zink vs. vsync? there's a peculiar issue with Darkplaces (a Quake 1 sourceport) on Zink if the game's vsync setting is disabled. it's much better with vsync on, but still slightly choppy.
<zmike> no, but I haven't specifically looked for such things
ella-0_ has quit [Read error: Connection reset by peer]
* ccr nods
<ccr> oddly enough Darkplaces seems to use just SDL2's SDL_GL_SetSwapInterval() and with other test programs I can't really see the same issue happening
<ccr> anyway, was just curious
<anholt> Anyone up for acking an NTT patch that's a big deal for wine on d3d9 hardware? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14309
<mattst88> anholt: on it
<danvet> javierm, yeah resources can only nest within whatever is there already
<danvet> we had epic amounts of fun with these for i915 reserved region, because a lot of bios would do off-by-one
<danvet> iirc we gave up
<danvet> I think in general drm pci drivers don't bother reserving their iomem regions
<javierm> danvet: got it. Thanks for the info
Major_Biscuit has quit [Ping timeout: 480 seconds]
rgallaispou has left #dri-devel [#dri-devel]
ahajda has quit []
mbrost has joined #dri-devel
mszyprow has joined #dri-devel
<jenatali> airlied: Let me know if you need help with the stupid nominmax stuff for the gl.h change
<jenatali> I'm wondering if we should just put that in the meson.build directly
<jenatali> Er, lean_n_mean I guess, not nominmax
<kts> I sincerely think the above two is related.
<kts> Both haswell
q66 has joined #dri-devel
<airlied> jenatali: yeah i suspect we should meson it
<airlied> since we seem to pick it up implicitly from gl.h which is bad to rely on
<jenatali> Yeah
mi6x3m has joined #dri-devel
<mi6x3m> Hey, can anyone tell me how I could 'link_whole' libi915 with libglx
<mi6x3m> meson tells me ERROR: Unknown variable "libi915".
<mi6x3m> but it exists in one of the child folders
<ajax> meson is an in-order language. if you descend into src/glx before src/gallium then none of the variables defined in src/gallium/**/meson.build will be available yet
<ajax> you probably need to do subdir('glx') after subdir('gallium')
<mi6x3m> ajax, ah, that is useful information
mszyprow has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
bl4ckb0ne has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
bl4ckb0ne has quit [Remote host closed the connection]
bl4ckb0ne has joined #dri-devel
ifreund has quit [Remote host closed the connection]
ifreund has joined #dri-devel
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #dri-devel
devilhorns has quit []
gawin has joined #dri-devel
pnowack has joined #dri-devel
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
mi6x3m has quit [Quit: Leaving]
gawin has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
ngcortes has joined #dri-devel
lcn has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
mi6x3m has joined #dri-devel
<mi6x3m> hey ajax, would you know what ibgallium_dri.so contains?
<mi6x3m> and also libglapi.so
<ajax> the former is every driver, linked together in a giant wad
<ajax> the latter is some API to manage opengl api dispatch tables
<airlied> jenatali: care to ack the 3rd patch on 14605?
<mi6x3m> should i expect problems with my static build because of glapi?
<jenatali> Looking
<airlied> jenatali: we can move to meson separately
<ajax> mi6x3m: i _think_ glapi should be able to work if you link the whole thing statically. haven't tried, obviously, but i don't think it does anything that really requires rtld services
<jenatali> airlied: Yep, LGTM
<jenatali> Windows can do a static glapi, it doesn't need to be dynamic
<mi6x3m> ajax, no i mean is it even relevant to me
<mi6x3m> to consider this library
<mi6x3m> so far i have gl, glex, libi915, libi1915drm
<ajax> you almost certainly do need it, i think. but why ask me, ask the linker. if you try to glue those all together and you get undefined references to symbols named _glapi_* then...
<jenatali> Yeah, glapi contains the thread-local dispatch table and current context storage
<mi6x3m> right let's see what mr linker says
camus1 has joined #dri-devel
mszyprow has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
Hi-Angel has quit [Quit: Konversation terminated!]
Hi-Angel has joined #dri-devel
gouchi has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Remote host closed the connection]
<mi6x3m> it appears i never knew mesa has C++ parts
<imirkin> mi6x3m: only glsl, clover, and many of the drivers.
Akari` has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
mlankhorst has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<zmike> ccr: heya new request: any chance you wanna add bold console escapes for tracediff on the REMOVED calls?
<zmike> it's super hard to notice if you're just scrolling through a trace that's 99% identical but is missing exactly 1 method
<zmike> or maybe add some **** or something in the center idk
<mi6x3m> is 'meson.build:529:6: ERROR: Problem encountered: dri based GLX requires shared-glapi' justified? I have the feeling that only GBM uses it and it's disabled in my build
<ajax> mi6x3m: you're now going far enough off-label that you should probably just try it and see ;) but to the specific thing, yes i think so. shared-glapi is mostly useful to make desktop-gl and gles both work in the same process, and i don't think that's a problem you're going to have.
<ajax> excuse me, "yes i think so" meaning "yes i think disabling that check is a move you should try"
<mi6x3m> ajax, yeah, indeed, i'm off road here but sometimes I have the feeling i'm hitting legacy stuff
<mi6x3m> but i do question my own sanity as well :)
<mi6x3m> thanks, trying!
<mi6x3m> gl and gles in 1 process sounds very bizarre
<ajax> think middleware where different parts of the program each have their own context
<mi6x3m> i know, but always impressed when I see that. I think i've used it in the past with OSmesa which IIRC uses swrast
Duke`` has quit [Ping timeout: 480 seconds]
<jenatali> IIRC it's also required for GLES just in general, since libEGL and libGLES both need to party on the same context and dispatch table
ngcortes has joined #dri-devel
<jenatali> Woo, finally hit ES3.1
<zmike> congrats!
<jenatali> Once that and tessellation land, I think I'm probably only a couple of weeks from 4.2 or 4.3
pcercuei has quit [Quit: dodo]
<daniels> jenatali: \o/ \o/
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<mi6x3m> 4.2 and 4.3 of what??
<imirkin> of GL
<mi6x3m> omg
<imirkin> jenatali: what are you missing (other than tess + ES 3.1 things)?
<mi6x3m> epic jenatali
<imirkin> can't think of anything particularly remarkable through GL 4.5. GL 4.6 may have some minor stuff? not sure -- most of it is supporting spirv, which is not-your-problem...
<jenatali> imirkin: FP64 (needs to be soft float on some GPUs I think), 64bit varyings, some more xfb extensions
<imirkin> ah, enhanced layouts? yeah i guess
<jenatali> Nothing too crazy, just plumbing, debugging, testing, etc
<jenatali> I don't think there's anything we can't support? Let me re-skim, I thought there was an extension we couldn't handle somewhere around 4.4 or 4.5
<imirkin> qbo?
mvlad has quit [Remote host closed the connection]
<imirkin> that one's a bit tricky
ngcortes has joined #dri-devel
<jenatali> GL_ARB_texture_mirror_clamp_to_edge
<imirkin> srsly? that's not in DX?
<jenatali> That's mirror-once, right? I don't think we do a mirror-once IIRC
mszyprow has quit [Ping timeout: 480 seconds]
<jenatali> Eh that's emulatable though with clamping to the [-2, 2] range though I guess
Lucretia has quit []
<imirkin> never thought about how to emulate
<jenatali> Oh nevermind, there is D3D11_TEXTURE_ADDRESS_MIRROR_ONCE
<imirkin> hw just supports it :)
<imirkin> yeah, that sounds simpler :)
<jenatali> Then yeah I think we can do everything else up to 4.6, cool. Just a matter of time/effort
<imirkin> hopefully there's nice support for ARB_qbo
rasterman has quit [Quit: Gettin' stinky!]
<imirkin> otherwise you're in for a bad time
<airlied> qbo is always a bad time even with support :-P
nchery has quit [Quit: Leaving]
<imirkin> that's fair :)
<jenatali> Yeah that was one of the changes from D3D11 -> 12, all query data is returned indirectly via a copy to a buffer
<jenatali> Should be fine
Lucretia has joined #dri-devel
<jenatali> Some D3D12 hardware I think gets stuck at GL3.3 / GLES3.0 though, the format support for image load/store is optional for us. I think the stuff that gets left behind is pretty old and not super relevant for us though
<jenatali> I really expected our Qualcomm drivers to fall into that category but was pleasantly surprised that they support all the necessary formats
<imirkin> when you say "format support" you mean storing without knowing the format up-front in the shader?
<jenatali> D3D doesn't support untyped load/store. The format doesn't need to be known in the shader, but only certain API-level formats can even have image views created
<imirkin> ah i see
<imirkin> well ES 3.1 has pretty limited requirements on formats
mi6x3m has quit [Quit: Leaving]
<imirkin> (more get brought in with NV_image_formats or whatever, but that's not required)
<jenatali> Ah maybe I'll update my checks based on whether I'm in an ES context then. I was just reading the core GL spec which has pretty broad format requirements
<imirkin> ES has some pretty harsh restrictions around formats
<imirkin> like if you want to read AND write, you have to use one of like 3 formats
<imirkin> (r32f/r32ui/r32i)
<jenatali> Yep, that's D3D's restriction too
<jenatali> At least, up until D3D11.3/D3D12
<imirkin> well, with desktop GL there's no such restriction
<imirkin> so i guess you're in for a bad time?
<jenatali> Yeah, I'm aware
<jenatali> It's optional to support more than that now, but most of our modern hardware does, so it should be fine. We're still in for a bad time though because GL requires casting by size, but D3D only does casting by class
<imirkin> ah right
<jekstrand> That'll be fun....
<jenatali> But yay shader lowering to the rescue >.>
<imirkin> there's actually some KHR-GLES31 tests that verify this
<jekstrand> For images, shader lowering will work. For textures, I see lots of image copies in your future...
<jenatali> Where does casting get required for textures?
<imirkin> ARB_texture_view, at least
<jekstrand> ^^
<jekstrand> Which is required for GL 4.something
<imirkin> 4.2 iirc
<jenatali> Ah, ARB_texture_view, yeah
<imirkin> this is the type of stuff that's so trivial in hw that i never think of it as being tricky
<jenatali> Ok so I guess we stop at 4.2 for now then
<jekstrand> I wonder how dozen will handle this... Maybe via the portability stuff? I don't see a way to insert the necessary copies in Vulkan[
<jekstrand> Not without carrying around a *lot* of simultaneous copies.
<jenatali> We're adding it to D3D for new versions. It just won't work on existing OSes/drivers
<jenatali> Like imirkin said, it works in hardware, there's no reason not to support it
<jekstrand> Intel's not going to like you for that. :)
<jenatali> We're taking the Vk1.2 approach with the cast list. For GL or the Vk1.0 casting flag it'll be the full by-size cast list, but for Vk1.2 we can scope it down
<jekstrand> right
<jekstrand> Is the new D3D interface going to have a cast list?
<jekstrand> Cool
<jekstrand> Yeah, Intel's CCS compression on SKL+ is designed around MSFT texture classes.
<imirkin> jekstrand: is the problem due to not all formats supporting the same tilings?
<jekstrand> If you cross classes, you have to disable compression.
<jekstrand> imirkin: They all support the same tiling but CCS compression works differently based on format.
<jenatali> Yep, we've heard
<imirkin> gotcha
pnowack has quit [Quit: pnowack]
eukara has quit []
nchery has joined #dri-devel