ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
jfalempe__ has quit [Read error: Connection reset by peer]
jfalempe_ has joined #dri-devel
rcf has quit [Quit: WeeChat 3.4.1]
sarnex has quit [Quit: Quit]
rcf has joined #dri-devel
rcf has quit []
rcf has joined #dri-devel
sarnex has joined #dri-devel
khfeng_ has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
yuq825 has joined #dri-devel
<mareko>
karolherbst: what did the LLVM commit your referenced fix?
<karolherbst>
RA doing broken stuff infinitly
sysescool_ has quit [Remote host closed the connection]
sysescool_ has joined #dri-devel
<karolherbst>
something the logic handling undefs was busted
<karolherbst>
so it resolved undefs and created new ones in a loop
<mareko>
karolherbst: do you mean infinite loop hangs? or infinite loops on the CPU?
<karolherbst>
on the CPU when compiling
<mareko>
ok
<karolherbst>
ohh btw, there was a reason I had to disable PIPE_CONTEXT_COMPUTE_ONLY and I think something wasn't working alright with the compute based blitter...
<karolherbst>
might investigate it once I start cleaning up the si MR
<karolherbst>
dunno if you encountered or are aware of something like this
khfeng_ has joined #dri-devel
slattann has joined #dri-devel
camus has joined #dri-devel
khfeng_ has quit [Ping timeout: 480 seconds]
<karolherbst>
illwieckz: guess you got your answers now :D
<karolherbst>
ehh.. somehow feels like a different bug *sigh*
camus1 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
sysescool__Linux has joined #dri-devel
sysescool_ has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
khfeng_ has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
slattann has quit [Quit: Leaving.]
lplc has quit [Ping timeout: 480 seconds]
xyb has joined #dri-devel
xyb_ has joined #dri-devel
xyb has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
slattann has joined #dri-devel
xyb__ has joined #dri-devel
oneforall2 has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: WeeChat 3.6]
oneforall2 has joined #dri-devel
xyb_ has quit [Ping timeout: 480 seconds]
lygstate has quit [Read error: Connection reset by peer]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
xyb__ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
sysescool__Linux has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
<airlied>
agd5f: what is drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h and why it all in hex?
<airlied>
are they shaders, are the sources somewhere? if they are fw they need to be loaded at fw time
FireBurn has quit [Quit: Konversation terminated!]
khfeng_ has quit [Ping timeout: 480 seconds]
<anholt>
karolherbst: that may have been somewhere in my tegra suffering, I forget though.
fxkamd has joined #dri-devel
Daaanct12 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
khfeng_ has joined #dri-devel
ngcortes has quit [Quit: Leaving]
khfeng_ has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Daaanct12 has quit [Quit: Quitting]
JohnnyonFlame has joined #dri-devel
camus has joined #dri-devel
<mareko>
airlied: it seems to be shader asm, the source code is in the asm files next to it
<airlied>
ah I missed the src code
JohnnyonF has quit [Ping timeout: 480 seconds]
* airlied
is blind
camus1 has quit [Ping timeout: 480 seconds]
<airlied>
since the patch changes the asm as well, thanks mareko !
<mareko>
the trap handler is like an interrupt handler running on CUs, it can also be invoked on page faults, division by zero, FP exceptions, etc. I guess something sends it a signal to interrupt and the trap handler saves waves to memory to emulate instruction-level preemption
<mareko>
I'm pretty sure this line in the gfx10 trap handler asm file isn't correct, and ACO folks can easily guess why: #if ASIC_FAMILY < CHIP_PLUM_BONITO
fxkamd has quit []
Company has quit [Quit: Leaving]
kts has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
camus has joined #dri-devel
mhenning has quit [Quit: mhenning]
camus1 has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
camus has joined #dri-devel
jekstrand has quit [Ping timeout: 480 seconds]
jekstrand has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
q66 has quit [Ping timeout: 480 seconds]
dcz_ has joined #dri-devel
q66 has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
mszyprow has joined #dri-devel
<dolphin>
airlied: able to check out the new drm-intel-gt-next PR? still looking for the backmerge to unblock patches
<dolphin>
I did say there was no big rush, but end of this week would be great, and we're kind of at Friday :)
camus has joined #dri-devel
bgs has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
danvet has joined #dri-devel
<airlied>
dolphin: let me see if I can squeeze it in
Daaanct12 has quit [Read error: Connection reset by peer]
jlawryno has joined #dri-devel
rasterman has joined #dri-devel
<dolphin>
airlied: thanks, when writing the pull req description, do note that there was now to tags that got merged at once, the first tag had bulk of the content
<mlankhorst>
robclark: Why are the I642U64 and U642I64 macros like that?
tursulin has joined #dri-devel
MajorBiscuit has joined #dri-devel
camus has joined #dri-devel
Major_Biscuit has joined #dri-devel
kts has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
lynxeye has joined #dri-devel
lstrano has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
apinheiro has joined #dri-devel
<MrCooper>
karolherbst: even if the regression is caused somewhere outside of the paths passed to git bisect, the guilty commit has to be somewhere in the range identified by the bisection with the wrong paths, doesn't it?
<MrCooper>
hmm, but doing another bisection in that range plus the original one with wrong paths might end up being more steps than just bisecting without paths in the first place
camus has joined #dri-devel
<karolherbst>
MrCooper: yeah... if the merges allign up really badly, and bisecting into the wrong merged tree, it can become quite a amess
<karolherbst>
especially on linux
camus1 has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus1 has joined #dri-devel
kts has quit [Quit: Leaving]
Daaanct12 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
jkrzyszt has joined #dri-devel
Lucretia has quit [Read error: No route to host]
camus1 has joined #dri-devel
Lucretia has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
swalker__ has joined #dri-devel
<eric_engestrom>
I just realized we report CI flakes to the IRC channels on the stable branch, but that's just unwanted noise, isn't it?
<eric_engestrom>
any objection to `sed /FLAKES_CHANNEL/d -i src/**/gitlab-ci.yml` on the stable branches? (and adding that to the release docs)
sysescool has joined #dri-devel
tzimmermann has joined #dri-devel
devilhorns has joined #dri-devel
Akari has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
camus1 has joined #dri-devel
kts has quit [Quit: Leaving]
warpme____ has quit []
theartist has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
orbea has quit [Remote host closed the connection]
<eric_engestrom>
anholt: ️☝️ since you wrote that flakes reporting code :)
<DavidHeidelberg[m]>
jenatali: I see you triggered " dzn: Propertly support format mutability ", could you cancel? I would retriggered right after Collabora farm gets though Marge-bot ;-) What you say?
<jenatali>
David Heidelberg: Sure thing
<DavidHeidelberg[m]>
Thanks :)
<jenatali>
Not in a particular rush, just fixed the build breaks so figured I'd go for it
<DavidHeidelberg[m]>
great. You get extra testing in ~ 30-40 minutes :D I think we can maybe just assign it again, because farm enabling is in the queue
<jenatali>
Extra testing on a change that'd have no impact to anything in the Collabora farm ;)
<jenatali>
But sure
<DavidHeidelberg[m]>
jenatali: I saw some Vulkan commit but I didn't dived deep
<jenatali>
Yeah, adding new functions only used by dzn atm
<DavidHeidelberg[m]>
jenatali: sorry about the fuss then :)
<jenatali>
No worries
slattann has quit []
jlawryno has quit [Quit: Leaving]
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
Grillo[m] has joined #dri-devel
jkrzyszt has joined #dri-devel
itoral has quit []
jkrzyszt has quit [Remote host closed the connection]
<theartist>
the only lead from LIBVA_TRACE log is: [60634.831765][ctx none]=========vaGetImage ret = VA_STATUS_ERROR_OPERATION_FAILED, operation failed
<theartist>
And after further discussion with #ffmpeg on libera I ended up here
<theartist>
Does anybody know how can I trace/debug this further?
jkrzyszt has joined #dri-devel
bmodem1 has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
<jenatali>
(Was checking if the messages were even going through)
kts has joined #dri-devel
<KunalAgarwal[m]>
ohhh
<KunalAgarwal[m]>
Let me see how to avoid that
<RSpliet>
Best way is to just not use a bridge and connect with IRC directly (or through your own bouncer - an old machine with ZNC would do, but is a slight faff to set up at first)
<jenatali>
The bridge is nice when it works though. Just keep the messages short and use multiple of em if you need
fxkamd has joined #dri-devel
<robclark>
mlankhorst: I suspect the reasoning was to handle negative ints
<KunalAgarwal[m]>
What I have is 2 framebuffers- input and output. I generate textures for each of them and want to perform rendering on the output texture.
<KunalAgarwal[m]>
P.S.The fixed-color.frag shader just aims to display whole screen as blue.
<KunalAgarwal[m]>
Just want to know If I am missing some function call or if the order of performing operations is incorrect
alatiera has joined #dri-devel
kts has quit [Quit: Leaving]
dviola has joined #dri-devel
devilhorns has quit []
<KunalAgarwal[m]>
What I can see: a screen affected by glClearColor()
aravind has joined #dri-devel
khfeng_ has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
Haaninjo has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
kts has joined #dri-devel
<agd5f>
airlied, yeah, what mareko said.
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
camus1 has joined #dri-devel
ybogdano has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
khfeng_ has quit [Ping timeout: 480 seconds]
fxkamd has quit []
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
tlwoerner_ has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Company has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
ybogdano is now known as Guest432
Guest432 has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
Peste_Bubonica has joined #dri-devel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
Peste_Bubonica has quit [Remote host closed the connection]
swalker__ has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
heat has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
bmodem1 has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
slattann has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
slattann has quit []
Peste_Bubonica has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
mairacanal has joined #dri-devel
srslypascal is now known as Guest438
srslypascal has joined #dri-devel
theartist has quit [Quit: WeeChat 3.7.1]
Guest438 has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
Peste_Bubonica has quit [Remote host closed the connection]
zehortigoza has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
khfeng_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
mhenning has joined #dri-devel
<Lyude>
13:32 <mdnavare> agd5f: Yes the validation and testing coverage benefits makes sense, any pain points that you have seen or have got feedback from the end users/ customers/any consumers in general? ← I would definitely say there's a few :\
<mdnavare>
Lyude: Could you throw light on some of them that you have experienced, so when/if we plan the same for Intel we can take those into account
<Lyude>
It's very difficult for outside contributors to get involved, especially because in general a lot of the abstraction makes working on amdgpu a lot different from other drivers because you're constantly trying to wrap your head around both the driver's abstraction and the rest of the DRM drivers. As well, I'd honestly say I've had a tremendously easier experience contributing to
<Lyude>
i915 from an outside perspective, as the code tends to be a lot more straightforward and easy to understand
<Lyude>
i'd definitely say this is true from my actual work responsibilities as well: the way intel's driver is setup right now is great, I can actually get documentation on how things work and potentially find issues where something was missed - and I've actually been able to build a fairly decent understanding of how intel's display hardware works in general
<Lyude>
it also makes it a lot easier to understand what/why we need to backport something, because we can actually more or less tell what most of the patches we're getting are actually doing
<Lyude>
we actually had a presentation that mentioned this during XDC as well iirc ("I'm not an expert, but…"), and I've gotten this feedback from a number of other folks that I've talked to
<Lyude>
erm - the complication around amdgpu I mean
<Lyude>
Probably worth noting too - I don't think a lot of folks realize that nouveau sort of has an abstraction like this. The difference is ours isn't really for cross-platform reasons, but mainly for handling plans for future fancy nvidia features. While I think ours does a pretty nice job of really strictly defining what should and shouldn't be in nvkm (nvif is the kernel interface for
<Lyude>
nvkm), it's still really nowhere near as straightforward as just having things not-abstracted and I still find contributors pretty often getting confused by it, myself included!
luc4 has joined #dri-devel
<Lyude>
so honestly, if you already have a well working driver imho it's probably better to keep things that way if you can
khfeng_ has quit [Ping timeout: 480 seconds]
<Lyude>
the least worse cross platform stuff would be basically as small as possible and leaving as much logic outside as possible, with only more complicated stuff like clock management/pm/reg programming/etc. being in the cross platform portion and having the rest of the driver just drive that. but there's not really any way of that happening without making things more complicated for
<Lyude>
pretty much anyone working on it outside of intel - so it's really not a decision that should be taken lightly imo
<Lyude>
take it from me - i'd probably remove the nvif/nvkm stuff in nouveau if I could :P
ybogdano has quit [Ping timeout: 480 seconds]
Akari has joined #dri-devel
<Lyude>
also, sorry to keep ranting - just something else I remembered as well. it's definitely caused friction in some places w/r/t getting code upstream in the past from what I've seen. There was the whole debacle around amdgpu getting accepted into the kernel initially (though it'd be fair to say thta wasn't -entirely- DC's fault, but it really didn't help), and I've also noticed a
<Lyude>
growing trend where we're very consistently getting contributors that are totally unfamiliar with how kernel contribs actually go and I've had a number of situations where I have to keep spending the energy explaining why we do cross-vendor code sharing in the kernel, why we do certain things in DRM like we do, etc. to a point it's honestly been kind of a burden. I'm fine with
<Lyude>
introducing new folks to linux kernel dev, but it's a lot more draining when the expectation becomes that if someone else takes on someone's work from AMD - there's a decent chance they may also have never worked on linux dev before and now I have to start all over again and usually bring up the same patch issues that haven't been addressed.
iive has joined #dri-devel
eukara has quit []
macromorgan has quit [Read error: Connection reset by peer]
<Lyude>
it is definitely by large the biggest timesink in that driver a lot of the time
<mlankhorst>
please burn nvif down
<mhenning>
to jump on the bandwagon, nvif has given me some headaches too and I don't even write kernel code, I just try to read it sometimes for the lulz
<mhenning>
although in fairness it isn't nearly as bad as the nvidia-developed spaghetti
luc4 has quit [Ping timeout: 480 seconds]
<Lyude>
yeah. the main reason for the sep in nouveau is because I believe we do have some actual cases where we will want nvkm/nvif separate eventually, but there's definitely already stuff we're trying to move out of nvkm
nchery has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
<airlied>
Lyude: I think it was originally for virt things
<Lyude>
airlied: yep
<airlied>
you'd passthrough nvif from the guest
jkrzyszt has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
<karolherbst>
please burn nvif down
<karolherbst>
ohh wait.. I could send patches
<karolherbst>
though I don't think the nvif model would be remotely secure
<karolherbst>
*even
Namarrgon has quit [Ping timeout: 480 seconds]
<karolherbst>
but dunno
<karolherbst>
by the time we support virt we already support it on the hardware level for all GPUs...
<Lyude>
if that ends up being the case we probably should consier removing it then
<karolherbst>
though not sure if some of the features will be quadro only
<airlied>
karolherbst: the nvrm virt model is similiar
Namarrgon has joined #dri-devel
<airlied>
they just route the rm api from guest to host
<karolherbst>
I see
apinheiro has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
srslypascal is now known as Guest446
srslypascal has joined #dri-devel
Guest446 has quit [Ping timeout: 480 seconds]
<jekstrand>
mareko: Is there a good reason why on-demand initialization of CPU caps is bad? I'm inches from NAKing all of !18751 and closing it.
<jekstrand>
I have yet to see a reason why we need global initializers, explicit or implicit.
<jekstrand>
It saves us one very cheap check which branch prediction will always get right.
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
<jekstrand>
Never mind. I just closed it.
<jekstrand>
If there's an actual problem to be solved or perf to be gained, we can re-visit. I don't see that happening.
mszyprow has joined #dri-devel
nchery has joined #dri-devel
rsjw has joined #dri-devel
<jenatali>
Good idea
mszyprow has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
khfeng_ has joined #dri-devel
khfeng_ has quit [Remote host closed the connection]
luc4 has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
camus has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
<jekstrand>
karolherbst: I'm starting to get uncomfortable with just how badly we're abusing explicit_io for kernel inputs
camus1 has quit [Read error: Connection reset by peer]
<karolherbst>
:)
<karolherbst>
well...
<karolherbst>
I try to unmess the situation at least bit by bit
<karolherbst>
I'd like to drop it and just use load_uniform (or maybe load_ubo) directly instead...
<karolherbst>
dunno
<karolherbst>
atm I handle that in rusticl now
<karolherbst>
having this "input" field is really just an artefact of clover now
<karolherbst>
and once we remove clover, we probably can get rid of a lot of madness here
<karolherbst>
in rusticl it's cb0 now, no exception
<jekstrand>
Even if we don't torch all of clover, can we torch the NIR path now?
<jekstrand>
Is there anything that's covered by that path which isn't strictly better with rusticl?
<karolherbst>
how comfortable are you feeling about making load_uniform be byte based?
<jekstrand>
It can be whatever is useful for the driver. load_uniform has always been flexible.
<mdnavare>
Thanks Lyude for all your inputs on the driver level code sharing approach, let me read through all of that and understand all the pain points so we can advice what direction to be followed for i915
<karolherbst>
jekstrand: sure.. but atm wth GL it's this "uint32_t or vec4" mess
<karolherbst>
and I don't want to get into that
<karolherbst>
the v3d compiler e.g. treats load_input also differently coming from vulkan or GL
<karolherbst>
I really don't like load_uniform
<karolherbst>
at this point load_kernel_input is this byte based "load from uniform/cb0" thing I know for sure isn't screwed up
<jekstrand>
Right
<karolherbst>
but I also don't see why that's related to the two patches tbh
<karolherbst>
well.. a little, but..
camus1 has joined #dri-devel
<karolherbst>
I think it's much better than what we had in the past though, now that I can just lower load_kernel_input to load_ubo
<karolherbst>
and drivers enabling lower_uniforms_to_ubo just work (tm)
apinheiro has quit [Quit: Leaving]
camus has quit [Ping timeout: 480 seconds]
rsjw has quit [Quit: rsjw]
gouchi has quit [Remote host closed the connection]
<karolherbst>
jekstrand: the only thing before torching the nir path is SVM support with nouveau, which _some_ are interested in having :(
<mdnavare>
that comes directly from HW like clk management/PM and reg programming to be done in a way that is shared with Windows and keep rest of it outside so Linux specific way
<mdnavare>
Lyude: the least worse cross platform stuff would be basically as small as possible and leaving as much logic outside as possible, with only more complicated stuff like clock management/pm/reg programming/etc. being in the cross platform portion and having the rest of the driver just drive that. but there's not really any way of that happening without making things more complicated for . On this are you suggesting having only the complicated stuff
<jekstrand>
karolherbst: But is anyone actually using that?
<jekstrand>
karolherbst: There's a difference between interest and users
<karolherbst>
sadly yes....
<jekstrand>
:-(
<jekstrand>
Ok...
<karolherbst>
for the most silly reasons you can ever imagine
<karolherbst>
also you probably now already 🙃
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<jekstrand>
*grumble*
nchery has joined #dri-devel
<mareko>
jekstrand: glUniform4fv for GLES mediump and glVertexAttrib4hNV and others from NV_half_float use the CPU caps to decide whether to use F16C for F16 conversions or emulate them, and the F16C instructions are pretty damn fast, leaving util_get_cpu_caps overhead potentially greater than the conversions
alanc has quit [Remote host closed the connection]