<ZeZu>
if it is using IL at that layer instead of IR that seems unnecessary if there were a MLIR I could target directly
<ZeZu>
I'm looking into things like NIR and DXIR, but again it's very slow going, so just hoping for some input
<HdkR>
So one problem is that you're still limited by what you can pass to the driver. So you're going to need to emit spirv or glsl at some point
<HdkR>
NIR isn't API stable and won't ever be. So it can't be shipped
<HdkR>
So even if you did use NIR as your IR (I don't recommend it for what you're doing) then you'd still need to do a NIR->spirv pass yourself
<HdkR>
A more optimal thing would be finding what is slow in those steps and take steps to rectify it. Either in your frontend for what you're passing to the driver, or fixing a pedantically slow path in the mesa stack
<HdkR>
You're never going to get rid of stutters in your shader JIT basically :)
imirkin has joined #dri-devel
<HdkR>
Well, an interpreter in your shaders might get you pretty far
<HdkR>
burn a bunch of compute and state bits for an interpreter before a thread compiling something specialized completes
<ZeZu>
Yes, i'm unfortunately familiar with at least some of the issues matching up graphics api to shader expectations , as it gets bad->worse for me there for a variety of reasons already
<HdkR>
I understand your problem space very well :)
<ZeZu>
Yeah I know
<ZeZu>
awesome progress w. fex btw
<HdkR>
Thanks!
<ZeZu>
Well thanks for replies, I had no expectation of finding a better solution than spir-v .. always worth a bit of thought on the topic anyhow.
smpl has quit [Quit: smpl]
Peste_Bubonica has quit [Quit: Leaving]
<HdkR>
ZeZu: If you find any pedantically slow patterns in the shader compilers then I'm sure someone can take a look at it though. Not many games will be abusing all the shader features like you do
<HdkR>
mesa with symbols plus perf likely could find some
<ZeZu>
I'm not actually at that point just yet, planning on actually writing the full shader [re]compiler now .. replacing some very wip code that mostly was just responsible for scraping resource descriptors to decode and order data for 'straight through' shaders.
imirkin has quit [Ping timeout: 480 seconds]
<ZeZu>
That alone can be a task, the graphics api they came from has full control of addressing as it's just a shim over GCN packets. IE: can write custom fetch shaders [simplest example]
<HdkR>
hehe. Yep
<HdkR>
When you have control at that level, it doesn't match the APIs very well
<ZeZu>
interpreter you spoke of earlier is somewhat of a requirement
<ZeZu>
it doesn't, thankfully most games used an intrinsic to setup register slots
<HdkR>
Just need to design around the worst case sadly
<Venemo>
I thought the designated initializers were already a c11 feature
<karolherbst>
Venemo: well.. in C++ you need like 14 or 17 to sue them
<karolherbst>
*use
<karolherbst>
I am actually looking forward using _Atomic and other nice to haves :D
<Venemo>
no they are not in either of those AFAIK, maybe in 20
<HdkR>
C++20 yes
<karolherbst>
uhh...
<Venemo>
I think the C and C++ committees are deliberately trying to make the two languages less compaible with thinks like these
<karolherbst>
I never get why those list initializers were the main thing but designated were not...
<karolherbst>
Venemo: yeah.. but in this case for stupid reasons
<Venemo>
the other one is complex numbers in C11
tobiasjakobi has joined #dri-devel
<Venemo>
that is just ridiculous how they had to invent new syntax instead of using what C++ already had
<karolherbst>
Venemo: well in C++ they use a class, no?
tobiasjakobi has quit [Remote host closed the connection]
<Venemo>
yes
<karolherbst>
well.. then C had to invent their own syntax, ni?
<karolherbst>
*no
<Venemo>
what stops them to use "complex<double>" instead of "double complex"?
<karolherbst>
the lexer and parser
<Venemo>
they could have just as easily invent "new" syntax that is closer to cpp
<karolherbst>
well you can't just change your language that it looks like something else
<karolherbst>
< is the less than operator
<Venemo>
yes, and?
<karolherbst>
so you can't juse use it for something else, because a different language is doing things one way
<Venemo>
it fit in C++'s lexer, it can certainly fit in C's
<karolherbst>
I find this particular argument a bit... well.. "I just hate C, because they are not C++" like
<Venemo>
I never said I hated C
<karolherbst>
tokens have meanings
<karolherbst>
Venemo: no, but your argument is just not great
<karolherbst>
feels like you are just trying to find something to make C look bad even though that's totally not on C
<Venemo>
but that said, I wish C had templates
<karolherbst>
they won't just start using the <> thing
<karolherbst>
and why should they?
<karolherbst>
just to look closer to c++?
<HdkR>
If C had templates you might as well as use C++ :)
<karolherbst>
that's a stupid reason
<Venemo>
not really
<karolherbst>
Venemo: right, but C doesn't
<Venemo>
I had the 'pleasure' of having to copy paste the same function with different types in it just because C doesn't have templates
<karolherbst>
and after you added all the features C is missing from c++ you could have just used c++ in the first place
<hch12907>
I'd like to have a C with Classes ;)
<karolherbst>
templates are not trivial to add
<karolherbst>
hch12907: you mean C++ without all the random crap? :p
<Venemo>
I don't miss classes from C, I just miss templates
<hch12907>
haha, precisely
<karolherbst>
apple has this boild down C++ inside XNU
<karolherbst>
where you can like use classes and a bit of inheritance
<karolherbst>
but not much more
<karolherbst>
*stripped
<karolherbst>
Venemo: sure, but templates are not trivial to add
<Venemo>
I didn't say they are trivial
<karolherbst>
also
<karolherbst>
you don't have to copy paste the same function
<Venemo>
what can I do, then?
<karolherbst>
a lot of people just do it because of broken compilers not doing c11
<karolherbst>
wait.. have to check the name
<Venemo>
I think macros can be used as sort of a "poor man's template", but I like that even less than the copy paste
<Venemo>
if you know of something else, I'm listening :)
<karolherbst>
mhh.. maybe you still need several impls, but you can share the same name on an interface level..
<karolherbst>
maybe _Generic can't do as much as I thought it could
<karolherbst>
but yeah, it still sucks
<Venemo>
sounds like they finally invented function overloading?
<karolherbst>
yep
<karolherbst>
it's even in the stdlib
<karolherbst>
tgmath.h
<karolherbst>
and others
<Venemo>
ah, it's just a macro under the hood basically
<Venemo>
meh.
<karolherbst>
yeah....
<karolherbst>
I think something like templates might be helpful but not templates like in C++ because that's just too much anyway
<Venemo>
yes, I would be happy to see some good mechanism in C to avoid copypasting this style of code
<karolherbst>
the annoying thing about macros is just writing functions is super annoying :D
<karolherbst>
I want c style macros
<Venemo>
maybe C++ templates are not the best, but there could be something that offers a similar functionality without macros
<karolherbst>
well.. in 20 years we just write rust anyway
<hch12907>
the problem with C style macros is that they use the preprocessor, which imo is annoying when it comes to stuff like error reporting
<karolherbst>
yeah...
<karolherbst>
although C++ is terrible if it comes to error reporting with templates anyway
<hch12907>
and to a lesser extend, usability... adding backslash to every line is quite annoying also
<karolherbst>
and without llvm...........
<karolherbst>
I mean.. even today it's super annoying, but pre llvm it was a disaster
<karolherbst>
macros have better error reporting than templates.. seriously
<hch12907>
yeah, tell me about it (while I read through a type name that goes through hundreds of lines :P)
<hch12907>
ah, std::string.
<hch12907>
I really like rust for this reason, better macros and _much_ better error reporting from the compiler.
<Venemo>
I don't get the hype about rust
ZeZu has quit [Ping timeout: 480 seconds]
<Venemo>
it's good that it solves memory safety, but other than that it seems like it just keeps much of the annoying stuff from C/C++
<Venemo>
also, just because an app is memory safe, doesn't mean it's safer in any other way
<hch12907>
true that, but the ownership system does reduce many accidental bugs
<hch12907>
like modifying a collection while iterating over it
<hch12907>
so basically if it compiles, it runs (most of the time, unless it's a logical bug)
GreatGodvin has quit [Quit: WeeChat 3.2]
<karolherbst>
the concept of secure by default is kind of what C and C++ misses
<karolherbst>
there are soooo many bugs everywhere, luckily most of them are not exploitable
<karolherbst>
even mesa has a bunch of data races
<HdkR>
Just go faster to win the race right? :)
orbea1 has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
* ccr
plays Initial D - Deja Vu
iive has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
GreatGodvin has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
GreatGodvin[m] has joined #dri-devel
GreatGodvin[m] has quit []
Thymo has quit [Ping timeout: 480 seconds]
GreatGodvin has quit [Ping timeout: 480 seconds]
Thymo has joined #dri-devel
blue__penquin has quit []
gouchi has quit [Remote host closed the connection]
bcarvalho__ has quit []
dv_ has quit [Quit: WeeChat 2.8]
tobiasjakobi has joined #dri-devel
atulu[m] has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
orbea1 has quit []
orbea has joined #dri-devel
gouchi has joined #dri-devel
dv_ has joined #dri-devel
ZeZu has joined #dri-devel
<cyrozap>
Venemo: If you're an excellent C/C++ programmer, then you probably don't see much benefit to using Rust, but I'm terrible at C and even worse at C++ and Rust's type safety and ownership rules keep me from shooting myself in the foot.
tobiasjakobi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<Venemo>
cyrozap: good to hear :)
<Venemo>
I wish I was an excellent C/C++ programmer
tobiasjakobi has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
<karolherbst>
cyrozap: I doubt anybody is excellent in C even less so in C++ :D
tobiasjakobi has quit [Remote host closed the connection]
* orbea
knows some people that are excellent in C
thellstrom has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
<cyrozap>
karolherbst: That's partly my point--a lot of the objections to Rust that I see are along the lines of, "but you can easily avoid the memory safety issues by only using modern C++, not using any of the 'bad' parts of C++, and not making mistakes in any C code!" But of course, knowing what parts of C++ are "bad" and shouldn't be used requires a certain amount of knowledge that bad C++ programmers like
<cyrozap>
me don't have, and I've never met someone who _never_ made mistakes when writing C, and encountered _lots_ of C code with memory and type-safety issues.
<cyrozap>
*and have encountered
<hch12907>
even in modern C++, there are a lot of footguns waiting for you to step on
<orbea>
cyrozap: the main objection to rust is the infrastructure around it, the language itself is a moot point
<cyrozap>
Basically, I don't like Rust because I'm a good programmer--I like it because I'm a terrible programmer who, despite that, still wants to build complex systems and be productive.
<cyrozap>
orbea: Yeah, there's definitely infrastructure concerns (like the hard dependency on rustc/LLVM).
<cyrozap>
And poor support in Meson and other build systems (because "you should just use cargo").
<cyrozap>
But I'm sure all those issues will be resolved eventually :)
gouchi has joined #dri-devel
<karolherbst>
cyrozap: the big issue is, that stackoverflow just has a lot of bad answers with terrilbe code :D
<karolherbst>
orbea: no, I wouldn't say that
<karolherbst>
the concept of safety by default is a game changer
<karolherbst>
especially for new developers
<karolherbst>
in C the first programs you write are all terrible code
<karolherbst>
with lots of memory issues
<karolherbst>
rust tells you outright what's wrong
<karolherbst>
so one of the major benefits is, that you don't start by writing shitty code
<karolherbst>
it's still not great, but not as terrible as with C or C++
sarnex has quit [Quit: Quit]
<karolherbst>
and the "now I have to unlearn what I've learned" problems is way smaller
<karolherbst>
*problem
<karolherbst>
but sure.. some people ignore that programming is mainly about learning and they stop to see the benefits
<karolherbst>
but those I would mainly just ignore :D
<karolherbst>
and I don't think there is much of a disagreement here except some uber C(++) loving fanboys who think that one can be a perfect programmer and you just have to learn enough or so
sarnex has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
<orbea>
any memory safety is just w/e at this point
<orbea>
7000+ lines of cargo culted deps including duplicate dependencies individually locked at various versions is just horrible from a maintainer and security perspective
<orbea>
imagine one of those has a critical CVE or something
<orbea>
especially if its something that every other crate depends on
<orbea>
in every project
<orbea>
(and in newer versions the API was broken so can't just blindly update it 30000 times)
<karolherbst>
orbea: ehh.. this file is autogenerated
<orbea>
doesn't solve the issue
<orbea>
you still need to fix your code when a crate breaks API
<karolherbst>
so?
<karolherbst>
then you have to do it
<karolherbst>
you also have to fix it if there is a bug
<orbea>
the reality people wont do it
<karolherbst>
then I won't their software
<karolherbst>
*use
<orbea>
they'll ship 3 different versions of something like base64 and dozens of other deps
<orbea>
(as that file already shows)
<orbea>
and imagine the fun updating your build when you are using extremely limited internet in some rural area as cargo starts to download it all :D
<karolherbst>
yeah well.. that happens if you depend on like tons of tools
<karolherbst>
orbea: with a normal linux distro you are screwed there as well
<orbea>
almost every rust project seems to have a problem like this to varying degrees, if its possible to avoid that would be better ofc
<karolherbst>
sure.. and dependency management is a huge painful point
<orbea>
yea, I seen people spend weeks on updates for distros in the past :)
<karolherbst>
but you compare a language with a proper versioning scheme with a language (C) where it's all convention and good luck
<karolherbst>
not sure what's better honestly...
<karolherbst>
forgot to bump your so file version and it crashes? good luck figureing out what went wrong
<orbea>
i know extremely clean and working C projects exist, but yea its very possible to do that terribly wrong too
<karolherbst>
C doesn't have any motion of dependencies, so it's hard to compare here anyway
<karolherbst>
and even in rust you can say: give me the latest version
<karolherbst>
and people should just do that
imirkin has joined #dri-devel
<orbea>
something I seen distros complain a lot with rust is dependencies that are locked to a maximum version and updating them on the distro side is painful
<karolherbst>
and actually
<orbea>
but I guess could just not do that
<karolherbst>
those are min version deps
tobiasjakobi has joined #dri-devel
<karolherbst>
not strict ones
<urja>
does rust versioning have any convention for API compatibility? like ... "give me the latest compatible version" is what you actually want (and maybe a warning if newer exists)
<karolherbst>
version = "0.6.0" actually means >=0.6.0
<karolherbst>
and.. <1.0
<karolherbst>
so you get the latest compatible one
<orbea>
hmm, maybe they changed it in rust
<karolherbst>
urja: yeah, that's the default thing
<karolherbst>
the lock file just contains whatever cargo came up with
<karolherbst>
or was able to find
<karolherbst>
of course if you have deps requiring a specific version you are doomed
<karolherbst>
ohh with 0.x you get 0.x and 0.x-1
<karolherbst>
interesting
<karolherbst>
ehh
<karolherbst>
+1
<orbea>
why does rust even need so many micro deps? Feels like perl or python, but worse in this regard.
iive has quit [Ping timeout: 480 seconds]
<orbea>
and still, if you have 10 rust projects as a maintainer and each of them specify "foo = 1.2.3", but that version has just revealed a critical bug that requires it being updated everywhere to "foo = 2.0.0", have fun!
<orbea>
this is why most distros uses shared libraries with C/C++ projects so that "foo" only needs to be updated once
<orbea>
and at worse, rebuild some projects
<karolherbst>
orbea: you don't update your project from 1.2.3 to 2.0 if you fix a critical bug :D
<karolherbst>
that's terrible maintainership
<orbea>
yea, but that is the reality of many projects
<karolherbst>
no?
<orbea>
convincing every project to do the right thing, not fun
<karolherbst>
stuff like that happens rarely for critical projects and at some point we will have better policies even inside rust when distros start relying on stuff
<orbea>
even if its "1.2.3" to "1.2.4" that won't be fun doing it 10 times in a row
<karolherbst>
you don't have to
<orbea>
or even more if its a critical dep everything uses
<karolherbst>
you get 1.2.4
<karolherbst>
even if you write 1.2.3
<orbea>
is "cargo update -p foo" run everytime a distro builds a package?
<orbea>
or is that something the package maintainer will need to do themselves?
<karolherbst>
you are not forced to have static libs with rust
<karolherbst>
and some distributions already ship rust libs as shared libs regardless
<daniels>
… and that’s even when you ignore things like everyone writing their own linked lists / growable arrays / hash tables because the stdlib might as well not exist
pcercuei has quit [Quit: dodo]
<orbea>
daniels: never claimed it was, only that dependecny proliferation is not an inherent part of C the way it is with rust or a lesser extent perl or python
<HdkR>
Obviously that sha1 implementation is performance critical and needs to use hardware sha instructions :)
<dcbaker>
daniels: so we're should use c++, which is basically c but actually provides those things ;)
andrey-konovalov has quit [Ping timeout: 480 seconds]
<daniels>
dcbaker: everyone loves the STL!
DPA has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]