ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<karolherbst>
why are some applications like "we make it impossible to debug our application with gdb"
heat has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
<oneforall2>
I predict gcc 11.3.0 should be in slack soon :)
<oneforall2>
karolherbst because they are diseased as ms developers that never want you to know their dirty little secrets .. :)
<karolherbst>
trying to run geekbench and all I get is a "[0425/023059:ERROR:src/geekbench/workload/compute_workload.cpp(116)] vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)"
<karolherbst>
and they kind of fork multiple processes, so my gdb either ends up in the parent or in some ghost bash shell
HankB has quit [Remote host closed the connection]
HankB has joined #dri-devel
<karolherbst>
yeah.. no idea.. maybe I compute something wrongly, maybe their code is crappy, I have now clue
chadv has quit [Remote host closed the connection]
chadv has joined #dri-devel
chadv is now known as Guest2731
kts has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
eukara_ has quit [Remote host closed the connection]
eukara_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
icecream95 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<graphitemaster>
It's amazing how poorly designed everyone is for multi-GPU even to this day. It reminds me a lot of the early days of almost all hardware on PC, the assumption that people would only have one audio device, one monitor, one microphone, etc.
<graphitemaster>
Like you'd think in this day and age that we'd be past making such a terrible assumption.
<graphitemaster>
Hardware singleton. Even multi-monitor support is bad, although it somewhat works (amazingly)
kts has quit [Quit: Konversation terminated!]
Company has quit [Quit: Leaving]
<imirkin>
gotta love that constructive criticism
Wally has joined #dri-devel
<Wally>
Is there any place I can get testing for Mesa(radv) changes?
Wally has quit [Remote host closed the connection]
Idwayb has joined #dri-devel
Idwayb is now known as Wally
<ishitatsuyuki>
Wally: wdym testing? Asking someone to test your patch?
Duke`` has joined #dri-devel
<Wally>
ishitatsuyuki: yes
<Wally>
Basically...
<ishitatsuyuki>
Wally: just open a MR (prefix draft in title if it's unfinished) and say *someone please test this* in description
<ishitatsuyuki>
note the platform that you have already tested or want somebody to test
slattann has quit [Ping timeout: 480 seconds]
<Wally>
ishitatsuyuki: k
slattann has joined #dri-devel
itoral has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
Wally has quit [Remote host closed the connection]
i-garrison has quit []
slattann has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
slattann has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
i-garrison has joined #dri-devel
danvet has joined #dri-devel
frieder has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
jkrzyszt has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
apinheiro has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
<kusma>
@jekstrand: alignof(void) is a gcc extension...
<kusma>
../../../source/repos/mesa/src/vulkan/runtime/vk_pipeline_cache.c(80): error C2714: alignof(void) is not allowed
<kusma>
../../../source/repos/mesa/src/vulkan/runtime/vk_pipeline_cache.c(81): error C2714: alignof(void) is not allowed
<kusma>
I'm kinda doubt you don't want an alignment of 1 here also...
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<tzimmermann>
javierm, i looked at the patchset, but I don't think we should land it
<kusma>
jekstrand: Actually, I guess an alignment of 1 might not be harmful here. So maybe switching to char for the type is better.
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<javierm>
tzimmermann: Ok, these changes were suggested by danvet. You raise a very good point about the possible multiple "system-framebuffer" device tree nodes
<tzimmermann>
javierm, let me send another reply with a much more simple approach
<javierm>
tzimmermann: I disagree with you about patch 3/5 though. I do think that the suggestion from danvet for that change is good
<tzimmermann>
well ok
<javierm>
tzimmermann: I have no strong opinion though, I'm OK with dropping that too patch if he agrees
<tzimmermann>
let's work on the overall solution first. give me a bit to write another reply to 0/5
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<javierm>
tzimmermann: great, thanks
pcercuei has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<tzimmermann>
javerm, i tried to break-down the problem to a simple scenario in my reply. maybe there's something that i don't see
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kj has joined #dri-devel
<javierm>
tzimmermann: no, you got it correctly. What you are describing is basically the fix for issue (2) that patch 4/5 already does
<javierm>
probably I should had split that in two patches...
<javierm>
tzimmermann: but that will still cause issues for the case of multiple system-frambuffers right? Since we don't want to disable the device registration for that case
<tzimmermann>
javierm, once we have at least one native driver, we know that there's something on 'some' display. i would not further bother with generic devices at that point.
<tzimmermann>
here's my scenario: we have multiple simple-framebuffers in the DT. these devices are created very early from the drivers/of/platform.c IIRC. and the firmware/bootloader might further select one of them and provide it as UEFI framebuffer
<tzimmermann>
there's a potential conflict that might be worth handling
<tzimmermann>
but if we successfully load a DRM/fbdev driver for at least one output, we know that the user wil get some display. so we can ignore generic devices after that
<tzimmermann>
we often do drm_aperture_remove_framebuffers() in drm drivers. that call unregisters all of the generic devices at once. so there'd probably be no change in behavior
JohnnyonFlame has quit [Read error: Connection reset by peer]
mclasen has joined #dri-devel
<tzimmermann>
i don't mind keeping 3/5 if it really is an improvement
<javierm>
tzimmermann: yes, agreed. And the case you mentioned is exactly what the sysfb_disable() call from remove_conflicting_framebuffers() in patch 4/5 was meant to solve
<javierm>
tzimmermann: and same, I don't really mind to drop patch 3/5 if you think that complicates the code more
<javierm>
in insight, I shouldn't had tried to include two independent changes in the same patch-set
ppascher has quit [Quit: Gateway shutdown]
<javierm>
tzimmermann: what do you think about this, I'll rework this with only the sysfb_disable() bits and drop all the locking changes, sysfb_try_unregister(), etc
<tzimmermann>
javierm, if you drop the whole sysfb_try_unregister() thing, it might be fixed already
<tzimmermann>
yeah, my thoughts
<javierm>
tzimmermann: it's fixed yes. It's just that while being there I did these changes suggested by danvet but are not really a requirement so let's defer that
<tzimmermann>
javierm, as i mentioned in one of th emails, i'd call sysfb_disable() after successfully registering the first driver
<tzimmermann>
makes it more robust
<javierm>
tzimmermann: I see. So not really at remove_conflicting_framebuffers() time
<javierm>
tzimmermann: problem is that we then will have to differentiate between simpledrm and real drm drivers
<javierm>
maybe we will need that flag after all
<tzimmermann>
why?
<tzimmermann>
oh, ok. i tihnk i see why
<tzimmermann>
for fbdev there's FBINFO_MISC_FIRMWARE already
itoral has quit [Remote host closed the connection]
<javierm>
tzimmermann: actually no, you are right and we don't need it. If isn't done at DRM driver register but DRM device register
itoral has joined #dri-devel
<javierm>
because even for simpledrm, that means that the platform device already was registered (by sysfb or otherwise) and sysfb could be disabled
<tzimmermann>
javierm, during boot, can it happen that we (1) register DT framebuffers, then (2) load simpledrm, then (3) register generic EFI, then (4) load simepldrm for EFI? would that create a bug somehow?
<tzimmermann>
maybe we should set FBINFO_MISC_FIRMWARE for simpledrm's fbdev emulation as well. so if we load a native fbdev driver, it would remove simpledrm
<javierm>
tzimmermann: hmmm, now you made me think about what would happen if we have a UEFI + DTB system and both the OF core and sysfb attempt to register a "simple-framebuffer" pdev
<javierm>
tzimmermann: regardless of this patch-set, it seems we have a race in that case currently
<javierm>
IOW, if the firmware could provide both an EFI GOP and a "simple-framebuffer" DTB node
<tzimmermann>
javierm, yeah i mentioned that briefly at [11:11:25]
<tzimmermann>
we could have two generic devices for the same I/O range here
<tzimmermann>
its a different problem though
<javierm>
tzimmermann: yeah, but wonder if that would be a firmware bug? In the sense that should be mutually exclusive ?
<javierm>
tzimmermann: yes, agreed that's a different problem
<javierm>
tzimmermann: setting FBINFO_MISC_FIRMWARE for simpledrm fbdev emulation makes sense indeed
<javierm>
tzimmermann: honestly, I believe that there should be a shared list of apertures between fbdev and DRM to avoid all these workarounds
<tzimmermann>
javierm, yes indeed
<tzimmermann>
somewhere in the kernel's i/o-mem code
<tzimmermann>
javierm, i have to go for lunch now. see you later
ella-0 has quit [Read error: Connection reset by peer]
<javierm>
tzimmermann: I need to find some time to dig deeper at drmlog, would be nice to completely disable CONFIG_FB
nchery has joined #dri-devel
slattann1 has joined #dri-devel
<karolherbst>
mhh.. how can I force the glcts binary to use a GLES context?
<karolherbst>
it tries to create this 4.0+ GL context and that fails on drivers not supporting it
<karolherbst>
mhh, seems like I should use the deqp-gles one, but that doesn't seem to find the test I want to run :(
slattann 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 [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
glehmann has joined #dri-devel
Major_Biscuit has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
jenatali: What would it take to make clang-cl (or mingw) able to build a working Mesa for Windows?
<alyssa>
a colleague mentioned there are DLL linkage issues specific to Windows (hence why we need MSVC compat for anything that might run on Windows)?
<karolherbst>
jekstrand: you know what's really missing to get rusticl to a point where we can call it a serious OpenCL implementation? :D
<alyssa>
karolherbst: dozens of vendor extensions that nobody uses? :-p
<alyssa>
Oooh, OpenCL C++ support? :-P
itoral has quit [Remote host closed the connection]
<karolherbst>
naaahh
<karolherbst>
that's easily added
<karolherbst>
especially OpenCL C++ support
<karolherbst>
OpenCL C++ is always offline compilation, so you have to use the SPIR-V ext for that
<karolherbst>
the only thing which we'd need to implement is ctors/dtors and those are just kernels which run once
<karolherbst>
and I think we also need to bind a global buffer for all kernels containing global state
<karolherbst>
nothing too complex
<karolherbst>
I am sure jekstrand knows what I mean :D
mclasen has joined #dri-devel
<pq>
not inlining all functions in kernels?
<pq>
i.e. function calls
<alyssa>
mm, kernels so massive that that matters, fun
<alyssa>
isn't opencl great? :-D
<karolherbst>
pq: bingo
<karolherbst>
alyssa: well..... I got a kernel with 2 millions ssa values
<karolherbst>
nir can crunch through that, that's not the problem
<karolherbst>
backends RA can't
<pq>
karolherbst, I read what you had written about it ;-)
<alyssa>
karolherbst: right, the traditional RAs in mesa are mostly quadratic complexity IIRC
<alyssa>
SSA-based RA in principle is linear, some details of coalescing notwithstanding..
<alyssa>
I am very curious how ACO fairs on that kernel
<karolherbst>
yeah.. no idea :)
<dschuermann>
ACO is also not really linear anymore on really large shaders, but the issue is spilling and not RA ;)
<jenatali>
alyssa: it already builds with MinGW. Clang-cl is even easier
<alyssa>
dschuermann: got it
<karolherbst>
yeah.. anyway, backends need to be able to call functions
<karolherbst>
but the implications here are what is annoying
<alyssa>
jenatali: oh?
<jenatali>
Clang-cl intends to be a drop in replacement. MinGW has some differences
<karolherbst>
yeah.. personally I wouldn't care about mingw too much as this entyre mingw situation is a bit messy anyway
<karolherbst>
*entire
<jenatali>
Yeah I don't get why anyone uses it when clang exists
<karolherbst>
because clang isn't GNU :P
<jenatali>
alyssa: was that question leading towards trying to drop MSVC compat?
<alyssa>
jenatali: I mean, maybe?
<alyssa>
Not specifically.
<karolherbst>
I'd nag MS into fixing their compiler :P
<jenatali>
At this point it's not about fixing, it's about adding GCC extensions that you folks want to use
<alyssa>
^^ that, I'm trying to understand the basis behind Mesa changes 'for' MSVC, and why MSVC can't be improved or an alternative compiler used instead
<alyssa>
Should we.. not be using GCC extensions?
<karolherbst>
jenatali: yeah.. I think at this point we might need to figure out what extensions we are using and which we don't need anymore
<alyssa>
I think I agree with karolherbst that that's the actual discussion to be having
<jenatali>
The big one I see is __typeof for C
<jenatali>
Which, IMO is only a problem because you're trying to use C ;)
<alyssa>
If it so happens that e.g void pointer arithmetic is actually Evil And Bad, then we should warn+werror on it for gcc and clang and it's not a question of MSVC compat, just fixing our code.
<karolherbst>
jenatali: ahh right...
<jenatali>
Yeah there's that one too
<karolherbst>
jenatali: but shouldn't __typeof be trivial for MSVC to add?
<alyssa>
but if void pointer arithmetic turns out to be Cool And Good, then I don't like Mesa not being able to use it because MSVC can't deal (and because MSVC is closed source we can't add support, etc)
<jenatali>
Yeah these things are probably easy to add. There is a public feature request tracker if you want to request it. I'll +1 it
<karolherbst>
yeah, I'd absolutely do that for typeof. I think GCC just added it, because they needed it for C++ anyway
* alyssa
has never used __typeof before and every example in Mesa is cursed what is this
<karolherbst>
they actually added auto to C as well
<karolherbst>
so there is __auto_type :D
<jenatali>
I do just want to make sure we're clear that they are non-standard and just adding them for compat with other codebases
<karolherbst>
alyssa: it's useful in macros
<karolherbst>
like in typed container ofs
<jenatali>
Yeah and MSVC can do it since it has decltype for C++
<alyssa>
right yes that
<karolherbst>
yep
<jenatali>
It just doesn't expose the C extension. Partly because it just never had good C support until recently probably
<karolherbst>
I think requiring typeof is a reasonable thing, and we should discuss this on each GNU extension we use
<karolherbst>
but I wouldn't want to depend on things we can easily workaround
<karolherbst>
workarounding typeof is pain
<jenatali>
Ehh it's not tooooo bad, but yeah
<jenatali>
IMO standards-compliance is kind of nice, but I'm obviously not going to have a major say here
<karolherbst>
anyway, it would help a lot of people, not just us :)
<jenatali>
karolherbst: agreed
<karolherbst>
asking for this GNU extension for variable sized struct is unreasonable, as it's part of the standard now
<karolherbst>
not sure if we use the C99 form everywhere
<karolherbst>
anyway.. we might want to compile mesa in a strict C11/C++14 mode and see what breaks
<karolherbst>
mhhh, I need to run something before gl_nir_lower_buffers and gl_nir_lower_images
<karolherbst>
actually.. I just want st/mesa to have a shared resource index for images and ssbos, maybe that wouldn't hurt too much, but I can see how that actually would
gouchi has quit [Quit: Quitte]
<karolherbst>
mhh, maybe image as derefs could help and I just lower images later after reindexing
illwieckz has joined #dri-devel
fxkamd has joined #dri-devel
* alyssa
tries to figure out what lowers function temps
<alyssa>
I guess vars_to_ssa?
<karolherbst>
alyssa: lower_io, no?
<alyssa>
or that.
<karolherbst>
vars_to_ssa helps to convert function_temps to SSA values
<karolherbst>
but for everything which can't be converted we have those load/store_scratch helpers
<alyssa>
right yeah ok
apinheiro has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
HankB has quit [Remote host closed the connection]
HankB has joined #dri-devel
Haaninjo has joined #dri-devel
cheako has joined #dri-devel
adjtm has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
jewins has joined #dri-devel
abws has joined #dri-devel
sdutt has joined #dri-devel
calebccff has quit []
calebccff has joined #dri-devel
Guest2731 is now known as chadv
Lucretia has quit []
ybogdano has joined #dri-devel
<kusma>
alyssa: just to be clear. MSVC support isn't a new requirement due to dozen / d3d12 etc. It's been there for years, just not systematically tested until recently.
Lucretia has joined #dri-devel
<kusma>
We didn't add MSVC support. We keep on repairing it when it breaks.
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
<alyssa>
kusma: Ack. That makes it all the more important to hear from all the relevant stakeholders and figure out the least worst option for everyone.
<kusma>
Right. But there's more stakeholders, that's my point.
illwieckz has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah, if it hadn't been there, it would've been a much bigger lift for us. I think we're just currently the most vocal / visible stakeholders at the moment
<kusma>
I think staying within the language we're using isn't a crazy idea, though. I don't think anyone is trying to write a significant amount of MSVC specific code here.
<jenatali>
Yup. Especially not us - we want to build using Clang/GCC to support WSL/WSA environments too
<alyssa>
Right, that makes sense.
<alyssa>
Right, that makes sense.
<karolherbst>
kusma: thing is just, that making things MSVC compatible actually makes things harder if we want to use rust inside mesa
<karolherbst>
but I am not sure how much of that is an extension
<karolherbst>
like bit enum fields
<jenatali>
Enum bitfields are fine. Just MSVC treats them as signed, so you need one extra bit
<jenatali>
Unless you make them explicitly unsigned
<karolherbst>
uhh
<jenatali>
(Unless I misunderstood what you were talking about)
<karolherbst>
yeah.. I don't want them to be unsigned, because then I end up in rust with u32 bindings vs the strongly typed enum :)
<karolherbst>
jenatali: I am only wondering where that actually matters
<karolherbst>
because if the enum value has 6 bit and the bit field is 6 bit, you still retrieve the correct value
<jenatali>
Reading the bitfield and then comparing against the enum
<jenatali>
Reading the bitfield sign extends because it's a signed value instead of zero-extend, so the comparison fails
<karolherbst>
yeah, that has to work regardless
<karolherbst>
no matter if the field is signed or unsigned
<karolherbst>
you get the original value, that's required by spec
<jenatali>
If it's a signed value, you need to reserve an extra bit for the sign bit
<karolherbst>
the spec disagrees
<karolherbst>
the compare has to be true
<karolherbst>
regardless if you have the additional sign bit or not
<jenatali>
Storing (2^6 - 1) in a 6-bit bitfield gives you different results if the type is signed vs unsigned
<karolherbst>
the spec still disagrees :D
<karolherbst>
the compare has to be true
<jenatali>
It's out of range if the type is signed
<karolherbst>
but it isn't
<karolherbst>
if the bit field is 6 bit, and the enum value has 6 bits as well, then it's all fine
<karolherbst>
at least fomr a spec perspective
<jenatali>
https://en.cppreference.com/w/cpp/language/bit_field: The following properties of bit-fields are implementation-defined: The value that results from assigning or initializing a signed bit-field with a value out of range, or from incrementing a signed bit-field past its range.
<karolherbst>
sure, but it's not out of range
<karolherbst>
the spec doesn't say about signed or unsigned
<karolherbst>
it specifies it on the size of bits
<jenatali>
2^6 - 1 is out-of-range for a signed 6-bit bitfield
<karolherbst>
doesn't matter for the spec
<jenatali>
It's in-range for unsigned
Duke`` has joined #dri-devel
<karolherbst>
the spec says "number of bits" not "sign extended value"
<jenatali>
"from assigning or initializing a signed bit-field" - clearly says signed
<jenatali>
I don't have the C spec handy, want to find me a spec quote?
<karolherbst>
yeah. working on that
<karolherbst>
ahh right.. the C++ spec isn't for free :)
<karolherbst>
what I found is that: "If the value of an enumerator is stored into a bit-field of the same enumeration type and the number of bits in the bit-field is large enough to hold all the values of that enumeration type, the original enumerator value and the value of the bit-field shall compare equal."
<karolherbst>
that's from section 9.6
gouchi has joined #dri-devel
<karolherbst>
jenatali: I am sure, that sign extension and stuff is allowed if you read the value out into something else thogh
<jenatali>
Huh. That does seem pretty clear to me, but also conflicts with the integral type wording
<karolherbst>
yeah...
<jenatali>
Hm, I guess if you directly compare the bitfield to the enum literal, then that applies, but if you first load the bitfield into a different var of the enum type, does it still apply?
<karolherbst>
I wouldn't say so
<jenatali>
In which case, IMO, the bitfields should still be one-bit larger
<karolherbst>
if you load it into a 32 bit value, you obviously need to sign extend
<karolherbst>
I guess
<karolherbst>
but.. not sure
<karolherbst>
maybe it depends on the type?
h0tc0d3 has joined #dri-devel
<karolherbst>
so if you compare enum to enum, then it has to be correct
<jenatali>
Pretty sure C says that all enums use 'int' as a base type
<karolherbst>
but if you store the enum mask in some unsigned value and compare that, then you have to expect sign extension?
<karolherbst>
mhh
<karolherbst>
maybe the C spec is different here... :(
* jenatali
shrugs
<karolherbst>
well
<karolherbst>
be it as it may, fixing/changing MSVC would break code I guess
<jenatali>
I prefer not to get into spec minutiae if I can avoid it, it seems simpler to either use 'unsigned' and be tight for bits, or use the enum type and add an extra bit to prevent sign extension
<karolherbst>
yeah.. I'd prefer the latter, because that makes my rust bindings nice
<karolherbst>
(also.. enum types get pulled in automatically)
Major_Biscuit has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah, so far it seems folks have preferred the former, to get tighter bit packing. I'm indifferent unless it's a perf-critical struct where one bit is going to make such a difference
<karolherbst>
did anybody actually checked if it might be fine to not use that additional bit?
<karolherbst>
not that it ends up as a "yeah, it has to be this way, but we never actually checked" situation
<jenatali>
Hm?
<jenatali>
Yes, I've made several changes to enum-bitfields that caused real failures when compiled with MSVC
<karolherbst>
I can see how that is not a comparison of enum types, but also would be interested if doing real ifs makes a difference
<jenatali>
It might? But also, having to do only that in order to be correct is a lot more fragile than just adding a bit or changing the type to unsigned
<karolherbst>
yeah...
<karolherbst>
oh wow that's annoying :(
<karolherbst>
I honestly don't see why using signed values makes any sense here, but... how did this even became part of the spec
<karolherbst>
but apparently negative enum values are a thing anyway
<jenatali>
Yes, they are
<karolherbst>
at least in C++ you can make the type explicit
<jenatali>
In C++14 I think, yeah
<karolherbst>
c++11 even
<jenatali>
Ah cool. That was an MSVC extension before it was part of the spec too
<karolherbst>
clang even added a warning for that: Wsigned-enum-bitfield
<alyssa>
karolherbst: -EIOIO
<alyssa>
signed enum
<ccr>
-EYOLO?
<jenatali>
Definitely read that as the Old McDonald chorus for a second
bluebugs has joined #dri-devel
<karolherbst>
jenatali: mhh.. I think non int bitfields are not even standardized at all
<karolherbst>
at least in C
<jenatali>
"whether int bit-fields that are not explicitly signed or unsigned are signed or unsigned is implementation-defined. For example, int b:3; may have the range of values 0..7 or -4..3 in C"
<jenatali>
Awesome
<karolherbst>
yes
<karolherbst>
it all sucks
<karolherbst>
but you can do "signed int"
<karolherbst>
so that fixes it
<karolherbst>
C is just broken
<karolherbst>
anyway, nobody should use "int" anymore
<jenatali>
Agreed. Which is why I wish Mesa had more C++
gawin has joined #dri-devel
<jenatali>
But alas
<karolherbst>
:P
<karolherbst>
C++ is even more broken
<karolherbst>
and broken in different ways
<jenatali>
Just in different ways
<karolherbst>
both a terrible languages
<zmike>
jenatali: while you're here, do you maybe know a ref for shaped windows api on msdn? I tried searching, but the results weren't exactly what I was hoping for
<zmike>
e.g., wglgears window has rounded corners
<jenatali>
Uh what are you trying to do? Remove rounded corners? Or add them?
iive has joined #dri-devel
<zmike>
detect them
<jenatali>
Ah...
<zmike>
need to query a hwnd to check
<zmike>
couldn't figure out how
<alyssa>
RiiR
<jenatali>
Yeah I'm not sure that there's really a good way, it depends on the theme IIRC, and if you override the wndproc to draw the non-client area yourself, you can draw the window in whatever shape you want
<zmike>
hm
<zmike>
maybe I should just use alpha always and see what happens?
<jenatali>
I'm still not sure the problem you're trying to solve :)
<zmike>
determining alpha for swapchain images
<jenatali>
I'd just always use alpha
<zmike>
🤔
<dj-death>
is there a NIR pass that removes blocks that are not reachable because preceding blocks have returns in them?
<zmike>
will see what happens I suppose
h0tc0d3 has quit [Quit: Leaving]
<karolherbst>
dj-death: opt_dead_cf? but that might depend on lowered returns :(
maxzor has quit [Ping timeout: 480 seconds]
<dj-death>
karolherbst: thanks a lot, I think it's exactly what I want :)
<cwabbott>
dj-death: return is a jump so it would be illegal to have blocks that "after it"
<cwabbott>
if it's something like an if where both sides end in jumps, opt_dead_cf handles that
<dj-death>
cwabbott: okay
<dj-death>
cwabbott: maybe I can extend opt_dead_cf for the nir_lower_shader_calls()
<dj-death>
which inserts a halt
<cwabbott>
dj-death: not sure exactly what problem you want to solve
<cwabbott>
I think because halt counts as a jump opt_dead_cf should already understand it
<dj-death>
cwabbott: you're suggesting it's illegal to have if () { ... } call() halt; if { ... }
<cwabbott>
dj-death: yes, that would be illegal
<dj-death>
cwabbott: if opt_dead_cf already optimizes that, then it's fine, I have nothing to do
<dj-death>
the problem is lower_shader_calls() might generate that
<cwabbott>
dj-death: yeah, you have to delete everything after the call() yourself before inserting the halt
<dj-death>
we do
<dj-death>
but it's still at the end of the block
<dj-death>
there is not validation error
<dj-death>
s/not/no/
<dj-death>
cwabbott: yet it's in the main body of the function so the anything after halt can be remove
<cwabbott>
dj-death: huh, yeah, looks like that's missing from validation, unless I'm missing it
<cwabbott>
but I don't think that was intentional
<cwabbott>
jekstrand is probably the only other authoritative source here, so if he agrees then it's definitely a bug
<cwabbott>
but in the example where there's an if after the halt, there would be a block with no predecessors and that would probably cause havok with everything else
<jekstrand>
What's a bug? What am I agreeing with?
<cwabbott>
whether something like "...; return; if (...) { } " should be illegal
<cwabbott>
apparently there's no validation for it
<dj-death>
jekstrand: I'm wondering if lower_shader_calls() can generate : if () { ... } call() halt; if { ... }
<cwabbott>
I think my intent was that a jump instruction has to be at the end of a cf list (in structured NIR)
<cwabbott>
but I can't find anywhere in nir_validate where we check that
<jekstrand>
dj-death: It's not too hard to nir_cf_extract(nir_after_instr(call), nir_after_cf_list(list)); instead of adding a dummy if.
<jekstrand>
Dummy ifs do sometimes make things easier, though.
<jekstrand>
And I thought lower_shader_calls already did that...
<jekstrand>
Hrm... No, we just remove everything up until the end of the block.
<jekstrand>
We need to remove everything up until the end of the CF list the block is in.
<jenatali>
Hm... there's no folks knowledgeable about Android hanging around here, are there?
<jekstrand>
Maybe stuffing it in a dummy list is the easiest thing to do for now.
<jekstrand>
jenatali: Few that will admit to it. :P
<jenatali>
I'm seeing missing synchronization and I'm wondering if we were always missing it and it just somehow didn't matter, or if it vanished at some point
<jenatali>
I'd assumed there was a glFinish() fallback path for when drivers don't expose native fence FD support, but... I can't find it
<jenatali>
Guess I'll have to hook it up
maxzor has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
LexSfX has quit []
LexSfX has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
ybogdano has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<alyssa>
Do we have shader replacement in VK?
illwieckz has joined #dri-devel
clever has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
clever has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
<alyssa>
..Where are these store_deref's coming from?!
<karolherbst>
alyssa: well if the nir is valid before, but not valid after, I guess either nir_validate is less than perfect or opt_sink is doing something crazy :p
<karolherbst>
alyssa: also, :D :D :D
<karolherbst>
(just saw your email)
<alyssa>
karolherbst: ;)
<karolherbst>
I was honestly a bit buffled by the question tbh, because..... :D
<alyssa>
it's a really weird case, uh
<alyssa>
phi ....., blockN: ssa_123
<alyssa>
ssa_123 gets sunk below blockN, which nir_validate says is invalid (use-before-def)
<alyssa>
but blockN is unreachable! it has no predecessors!
<karolherbst>
mhh
<karolherbst>
weird
<alyssa>
aco seems to special case this
<alyssa>
/* NIR seems to allow this, and even though the loop exit has no predecessors, SSA defs from the
<alyssa>
* loop header are live. Handle this without complicating the ACO IR by creating a dummy break.
<karolherbst>
"seems to allow this" is asking for troubles
<jekstrand>
yeah....
<alyssa>
can't tell if opt_sink is misbehaving, or it's being clever on goofy NIR.
<alyssa>
also not sure why this hasn't been a problem before, I guess pass ordering
<karolherbst>
you could print the before and after and we might be able to tell :D
<karolherbst>
jekstrand: I like how you feel nomentioned :D
<alyssa>
I mean. I guess those numbers could look worse, everything considered.
<alyssa>
NIR validation failed after nir_lower_blend
<alyssa>
Ooh this one's probably my fault
<jekstrand>
alyssa: Anything I could help by looking at? I'm afraid that operation test may be out of my knowledge base when it comes to why Mali would be falling over.
<alyssa>
jekstrand: I don't know yet.
<alyssa>
The operator one is the one I'm tripping over. and if our combined brains can't get that, I'll have to hope for a boris ex machina :p
<jekstrand>
alyssa: What's the ENV var for dumping all the state and stuff?
<karolherbst>
:(
<alyssa>
jekstrand: PANVK_DEBUG=trace
<alyssa>
and BIFROST_MESA_DEBUG=shaders
mhenning has joined #dri-devel
* jekstrand
builes origin/main on his vim3
<alyssa>
hf
<alyssa>
oh, I see what's happening with this one
<alyssa>
stupid
<jekstrand>
?
<alyssa>
the lower_blend test
<alyssa>
conceptually something like
<alyssa>
`out float fragcolor`
<alyssa>
but RGBA render target
ybogdano has quit [Ping timeout: 480 seconds]
<alyssa>
and so load_output() is only getting a scalar but the blend calculations need the whole vector
<alyssa>
wonder why that's not a problem with GLES
<alyssa>
I guess it would be if we lower_blend'd directly in panfrost, as opposed to hiding behind a blend shader.
<alyssa>
Vulkan has layered rendering on devices without geometry shaders?!
<bcheng>
is it possible to have multiple processes to use different drm planes at the same time?
jacky has joined #dri-devel
jacky has quit []
<graphitemaster>
Wonder if anyone has done benches of the d3d12 driver and zink on windows to see which has the better performance for running gl applications
<alyssa>
ERROR - dEQP error: NIR validation failed after nir_lower_vars_to_scratch
<alyssa>
oh come on!
ybogdano has quit [Ping timeout: 480 seconds]
eukara_ has joined #dri-devel
eukara has quit [Read error: No route to host]
lanodan has quit [Ping timeout: 480 seconds]
bbrezill1 has quit [Ping timeout: 480 seconds]
zf has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
enunes has joined #dri-devel
apinheiro has quit [Quit: Leaving]
jewins has quit [Ping timeout: 480 seconds]
eukara_ has quit [Ping timeout: 480 seconds]
<jenatali>
graphitemaster: I expect an "it depends" answer based on the underlying D3D/VK drivers, but if I had to guess, probably zink would win in most cases
maxzor has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
<jekstrand>
alyssa: Why is VIEWPORT::Max/MinimumX/Y set to +/-inf?
* karolherbst
gets an headache just thinking about the work it means implementing function calls
tursulin has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
jekstrand: because legacy baggage
<alyssa>
those fields are only used for clipping wide points and lines
moony has quit [Ping timeout: 480 seconds]
<alyssa>
conformant behaviour on any reasonable API is achieved by setting them to +/-inf, always
<alyssa>
the actual viewport is specified as system values and used by the VS (which spits out screen space)
moony has joined #dri-devel
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<Kayden>
nchery: now that I've looked at the ASTC transcoding format selection stuff a bit more...I'm not really sure quite what to do for dynamically selecting BC1 vs. BC3/7
<Kayden>
one snag I didn't realize is that the ASTC decode step is called in st_UnmapTextureImage, one slice at a time. and encode is done there too. so it's possible that we could select BC1 for one array slice, only to discover that another slice needed alpha, and we needed BC3/7 after all
<Kayden>
so it seems like we either have to analyze up front (oof, overhead), or...defer the transcode until we've seen all slices - assuming we even do...
<Kayden>
or we could transcode to BC3 and do a post-processing step in the case of no alpha where we rip it in two and save the BC1 parts but toss the BC4 aspect
<Kayden>
or do an ugly texture validation type hack where we have multiple slices in different formats and...piece it together at the end (yikes)