<DPA>
> The sizeof operator yields the size (in bytes) of its operand ...
<DPA>
> The result is an integer.Ifthe type of the operand is a variable length arraytype, the operand is evaluated; otherwise, the operand is not evaluated and the result is aninteger constant.
<DPA>
Seams pretty clearly defined to me.
slattann has joined #dri-devel
<emersion>
hm, new in C99
<shfil>
so it works both for `int array[];` and `int array[0];`?
<emersion>
yea
<emersion>
ah
<emersion>
wait
<emersion>
is this inside a struct?
<emersion>
if so, this isn't a VLA
<emersion>
it's a "flexible array memeber" or something
<emersion>
and you can't sizeof() it
<DPA>
Correct, at least for the "int array[];". "int array[0];" is just an array with size 0, which the standard doesn't allow, so it's ub.
<shfil>
sometimes I think "c" is more complicated than c++ (when you include all these extension and custom versions)
<shfil>
like now
iive has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
andrey-konovalov has joined #dri-devel
camus1 has quit []
sdutt has joined #dri-devel
NiksDev has joined #dri-devel
slattann has quit []
andrey-konovalov is now known as Guest5482
Company has joined #dri-devel
Guest5482 is now known as andrey-konovalov
andrey-konovalov is now known as Guest5484
Guest5484 is now known as andrey-konovalov
mbrost has joined #dri-devel
andrey-konovalov has left #dri-devel [Leaving]
<karolherbst>
just use C11 then
<karolherbst>
we do require C11 now, so we might want to cleanup all the non default things which are covered by C11
nchery has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
bcarvalho has joined #dri-devel
slattann has quit []
bcarvalho has quit [Remote host closed the connection]
dreda has quit [Remote host closed the connection]
dreda has joined #dri-devel
Company has joined #dri-devel
<ajax>
karolherbst: where do we say we require C11?
<karolherbst>
but the threading stuff is also neat
<ajax>
i want anonymous aggregates
<karolherbst>
ahh
<ajax>
and i'm somewhat surprised we haven't tried _Generic() in a few places to avoid going full c++ template
<karolherbst>
mhhhh
<karolherbst>
_Generic is a bit... annoying
<karolherbst>
but yeah
<karolherbst>
but we could start by using tgmath.h instead of math.h
<karolherbst>
could allow us to get rid of a few loc
<karolherbst>
but I think that's c99, isn't it?
<shfil>
though it's more prefer c11 than require c11?
<ajax>
tgmath is c99, _Generic is c11
<ajax>
presumably everyone ended up implementing the latter in order to implement the former
<karolherbst>
ahh
<karolherbst>
shfil: well... you default to c11
<karolherbst>
people start using c11 features
<karolherbst>
compiling with c99 breaks
<karolherbst>
so where is the difference?
<karolherbst>
ajax: yeah
pekkari has joined #dri-devel
<karolherbst>
shfil: we don't CI with c99
<karolherbst>
so compiling with C99 is broken ¯\_(ツ)_/¯
<shfil>
uh, maybe I should say this way: it's not clean c11
<karolherbst>
result is we require C11
<karolherbst>
shfil: ohh, of course not. I mean, it was C99 and we still have all the wrappers
<karolherbst>
so yeah
<ajax>
i'm just so used to avoiding even the innocuous bits of c99 because Portability™ that c11 feels like waking up on DS9
<karolherbst>
:D
<karolherbst>
yeah
<karolherbst>
but things like _Atomic makes it soooo easy to use atomic
<karolherbst>
s
<HdkR>
Just use volatile </s>
<shfil>
iirc flag %m (heavily used in mesa) is for from some extension
<karolherbst>
and I will still use simple_mtx_t because it's faster than mtx_t
<shfil>
flag for scanf, iirc some posix's extension
JohnnyonF has joined #dri-devel
<karolherbst>
shfil: I don't think it's an extension actually
camus has joined #dri-devel
<karolherbst>
yeah
<karolherbst>
even POSIX mentions m
<karolherbst>
"If the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically."
<DPA>
Stuff like _Atomic is optional in C11, and before it was fully supported in gcc / glibc, __STDC_NO_ATOMIC__ used to be wrongly not defined, before it just got implemented. It is really nice when available, but I don't know how well the various compilers nowadays support it.
<karolherbst>
DPA: they do, there is just hardware without support for atomics
<karolherbst>
hence it being optional
<karolherbst>
but for all the hw we care about there should be atomics
<DPA>
Ok, good.
idr has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<karolherbst>
I thought there was a table somewhere
JohnnyonF has quit [Ping timeout: 480 seconds]
<karolherbst>
but maybe MSVC is still stupid
<karolherbst>
dunno
sdutt has quit []
sdutt has joined #dri-devel
bcarvalho has joined #dri-devel
<shfil>
btw what do you use for bouncing IRC messages on yours vps?
<ajax>
ngh. anonymous aggs don't work like i want. if struct b is already defined then struct a { struct b; int _a; int _b; } ought to be the obvious way to subclass. right?
<ajax>
but no:
<ajax>
../src/glx/drisw_priv.h:38:33: warning: declaration does not declare anything 38 | struct glx_context /* base */;
<karolherbst>
mhh
<karolherbst>
I don't think it works like that
<ajax>
i mean, clearly not ;)
<karolherbst>
you can have anonymous internal structs, but I doubt you can just "include" already defined ones :D
<karolherbst>
but
<karolherbst>
nice thinking
<emersion>
shfil: do you eman, which irc bouncer?
<emersion>
mean*
<ajax>
sigh. yeah, why make C subclassing look obvious. who does that, only every C project, who cares.
<shfil>
emersion: yeah, I need to setup something
<ajax>
(i'm just kvetching, you can ignore me ;)
<emersion>
shfil: shameless plug: soju
<ajax>
i think -fplan9-extensions does this? maybe?
<karolherbst>
ajax: I guess they didn't want to run into this problem with shadowing variables, once the parent struct changes
<shfil>
emersion: thx gonna try
mbrost has quit [Ping timeout: 480 seconds]
aravind has quit []
poacher_ has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<ajax>
karolherbst: that's... a weird justification.
<danvet>
robclark, can you also stamp the other msm patches? ideally also some of the shared code ones
<karolherbst>
ajax: ehh.. I was just thinking and came up with this problem, no idea what was discussed and if it was even proposed
<ajax>
yeah
oneforall2 has quit [Quit: Leaving]
JohnnyonFlame has joined #dri-devel
oneforall2 has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
mbrost has joined #dri-devel
frieder has quit [Remote host closed the connection]
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
gouchi has joined #dri-devel
tobiasjakobi has joined #dri-devel
tzimmermann has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
<jekstrand>
Anyone here familiar with irqchip?
mlankhorst has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
<jekstrand>
We've got a pile of IRQ handling junk in i915 and I'm trying to figure out if irqchip would help at all.
<jekstrand>
danvet suggested I look at it but he doesn't seem to know much more than its existance. :P
ngcortes has joined #dri-devel
<danvet>
jekstrand, anholt_ maybe, or anyone who brings up armsoc, afaik they're heavily used there since absolutely everyone loves to invent new irq controller rtl for lolz
<jekstrand>
I thought maybe robclark might know too
<jekstrand>
There's definitely lots of IRQ lolz in our gfx HW.....
<robmur01>
do you have an actual secondary IRQ controller in the GPU, or is it all just stuff at either end of normal PCI IRQs?
<robmur01>
former case yes, latter case no.
<jekstrand>
Normal PCI IRQ, I think, with lots of register whacking lolz to sort out the 3-4 levels of indirection.
<danvet>
my layman understanding is that we could model each level/irq register group as a irqchip maybe
<danvet>
they nest a few levels deep and there's a ton of them
orbea1 has joined #dri-devel
<danvet>
with a handful of standard patterns of how the registers work
<jekstrand>
With a new standard every generation!
<danvet>
one is 4 registers: current irq source status, mask for saving to sticky register, sticky, and enable mask for irq forwarding to the next level up
<danvet>
the other is just irq sources with no mask and just the sticky one
<danvet>
also different rules for clearing
orbea has quit [Ping timeout: 480 seconds]
<danvet>
there's a few more
orbea1 has quit []
nchery has quit [Ping timeout: 480 seconds]
orbea has joined #dri-devel
<danvet>
also tbh no idea whether fanning this out fully as interrupt sources would be too much locking
<danvet>
currently we only have a handful of spinlocks for it all
<jekstrand>
How does nesting work with something like irqchip? Define another driver on top with a different string/path thing and the lower level one fires off SW interrupts which higher levels pick up?
<robmur01>
hmm, if it's multiple independent sources which end up getting muxed into PCI IRQ(s), it does sound like it might kinda fit the secondary IRQ controller approach
<jekstrand>
Yeah, there are a couple different display sources as well as N GT sources (one per HW engine) which get multiplexed into a single PCI interrupt and then we have to fan it back out.
<robmur01>
request_irq() for all the individual sources might end up looking a bit funny, and make a mess in /proc, but it could work
<robmur01>
probably worth taking a browse through drivers/gpio for examples of relatively simple irqchip implementations
<jekstrand>
How much overhead would it add to have a bunch of different request_irq()? Does it have to ping-pong through some central handler for every level of indirection?
<robmur01>
there's a fair amount of bookkeeping in the IRQ core
nchery has joined #dri-devel
<jekstrand>
hrm...
tobiasjakobi has quit [Remote host closed the connection]
<jekstrand>
Then maybe we're better off coming up with a better way to structure what we have.
<robmur01>
I would expect demuxing through chained IRQ handlers to be a bit less efficient than what you can open-code in the driver without any abstraction, but I don't know enough to guess at exactly how much
<shfil>
can someone assign Marge to these 2 MRs? thx
<robmur01>
overall I think I'd rank the idea as "worth trying for a laugh, but don't be surprised if turns out a bit rubbish" :)
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<robmur01>
although TBH looking at i915_irq.c and i915_gt_irq.c I suspect you'd basically still have all the same code, just moved around a bit and wrapped in yet more code for the irqchip abstraction
<robmur01>
anything which could be generalised for the sake of abstraction could presumably be generalised in the existing functions anyway
slattann has quit []
jhli has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
shfil has quit [Ping timeout: 480 seconds]
<robclark>
jekstrand, danvet: one of the advantages of irqchip, which might not apply in your case, not sure, is dealing with code shared between older platforms with dsi/hdmi/disp/etc irq's coming directly from the toplevel irq controller vs newer gens where there is a single irq into mdss and demuxing with mdss.. all of the dsi/hdmi/dp/disp/etc sub-drivers just request_irq() and don't have to care about the difference
<robclark>
that said, I've not seen perf issues with it.. but there is only a single level of demuxing
pekkari has quit [Quit: Konversation terminated!]
tzimmermann has quit [Quit: Leaving]
JohnnyonF has joined #dri-devel
shfil has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
camus has quit []
poacher_ has quit [Remote host closed the connection]
macromorgan has quit [Quit: Leaving]
tobiasjakobi has joined #dri-devel
macromorgan has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
bcarvalho has quit [Remote host closed the connection]
<airlied>
jekstrand: my guess is that irqchip won't buy you anything for the mess that is i915 irqs :-P
mbrost has joined #dri-devel
heat has joined #dri-devel
rcf has quit [Quit: WeeChat 3.1]
rcf has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
FLHerne_ has joined #dri-devel
FLHerne has quit [Read error: Connection reset by peer]
hansg has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
<jekstrand>
airlied, robclark, robmur01 Yeah, It sounds like we should keep it hand-rolled in the driver. I was hoping it could end up a bit cleaner but I think it's going to be a mess no matter what. :-(
jernej_ has joined #dri-devel
jernej has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
<HdkR>
Has anyone noticed that when you're running a Vulkan application, every Vulkan driver registered in the ICD is loaded and stays loaded?
<ajax>
ayup
<HdkR>
Feels like a VA killer for 32-bit applications for say....zink
<zmike>
na we good
<HdkR>
32-bit VA space problems resolved? :P
<zmike>
phoronix says yes
<HdkR>
huh
<HdkR>
Surprising
<ajax>
how in the world is lavapipe 2M of .data
<ajax>
how many times do i need to fix this
<HdkR>
:D
<ajax>
of course. because it's every driver, because it's nir_opt_intrintic
<HdkR>
libLLVM-12.so.1, just a casual 90MB
<HdkR>
I shudder to think what happens when you have the nvidia blob and a few more Vulkan drivers installed is like
<ajax>
the megabytes it costs probably vanishes next to the gigabytes of texture data, but yeah
<ajax>
we're certainly doing worse than we need to
<airlied>
HdkR: could propose to fix the loader
<airlied>
but I think once you create an instance you are in a bad place
jernej_ has quit []
danvet has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit [Remote host closed the connection]
<karolherbst>
HdkR: that's a valid concern once you have 2 120GB games installed
jernej has joined #dri-devel
<Venemo>
Hey guys
<Venemo>
I have a stupid shader that does fddx_coarse with an undefined operand
<Venemo>
I'm wondering would it be okay to constant-fold that to 0?
<pendingchaos>
I think so
<pendingchaos>
fddx_coarse(0) is 0, and undefined can be zero
<Venemo>
For that matter, the derivative of any constant or uniform source could be folded to zero
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
jhli has quit [Remote host closed the connection]
shfil has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
iive has quit []
lemonzest has quit [Quit: Quitting]
ngcortes has quit [Remote host closed the connection]