ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<unique_id>
I should have said this earlier. I guess I was trying to balance what other people have said about Vulkan with my experience, like one Khronos member once said "Vulkan is not low level" it justs fits the hardware better but that isn't true. Examples:
<unique_id>
For proper usage you'll have to suballocate the memory you get from Vulkan. So you'll either write your own allocator or use a library. You'll have to handle low memory situations yourself. AMD has 256 MiB of special device local memory thats host_local but you should probably make use of it as normal memory if device_local memory is low. So we're already writing vendor specific code here, but you can make it generic so it'll
<unique_id>
work if other devices have such memory.
<unique_id>
You don't have to do this, but if the computer is low on vram then your app will perform worse than on OpenGL if you don't. What's more? Integrated GPUs vs dedicated GPUs. Dedicated GPUs have device_local memory which is a pain to move things to. On Integrated GPUs you'll have to not do that, and not doing things is also work.
<unique_id>
Descriptor Sets are a pain to learn. And as with everything in Vulkan you have maximum freedom. You can pick from a number of strategies with regards to Descriptor sets and this isn't something an app developer should have to think about
<unique_id>
I haven't checked out Metal but it is probably what OpenGL Next should have been. Vulkan should be buried in the deepest and darkest corners of huge game engines, and nowhere else.
<unique_id>
But it's up to you :)
<unique_id>
host_visible* (not host_local), not that it matters
<unique_id>
It might seem surprising, but it actually takes a lot of work to reach OpenGL's GPU (not CPU) performance with Vulkan, simply because you're sort of taking the role of the driver writer. On the CPU side you'll destroy OpenGL, not so on the GPU side.
<andrewrk>
whew. finally finished basic fs watching support on all supported platforms
<andrewrk>
now just a couple platform-agnostic bugs to fix and I can merge this monster branch
<scientes>
sweet
<andrewrk>
unique_id, brb I'm going to grab some food and then read your messages
JinShil has joined #zig
<unique_id>
I would conclude that for games Vulkan is overall great but for non-games there are a lot of concepts that you really don't want to be thinking about when trying to work on your app. If we had Metal the choice would be easy.
tuckerkevin has joined #zig
<andrewrk>
unique_id, I've 2 ideas upon reading your comments -
<andrewrk>
one is that, eventually we would want an implementation of some kind of graphics in vulkan in zig just to avoid a C library dependency. the holy grail is a multimedia application with no libc dependency
<andrewrk>
and another idea is - maybe we shouldn't be caring about the graphics card at all. maybe we should be doing 100% CPU rendering
<scientes>
mmap() should return [*]u8, not usize
<scientes>
or hell, it could even return []u8 using the length parameter
<scientes>
but i guess these are raw interfaces...
<andrewrk>
scientes, what type safety would [*]u8 provide instead of usize?
<scientes>
none
<scientes>
var db_fd = linux.open("/var/cache/command-not-found/db\0", linux.O_RDONLY, 0);
<scientes>
how am i suppose to make zero-terminated string before #265 gets fixed
<kristate>
andrewrk: I am in a meeting, but want to get your thoughts on var args in os.posix.*
<kristate>
up until now we don't have a var args function included, so I didn't have any examples to go on
<andrewrk>
hi kristate
<kristate>
I think we have the same tastes and writing varToSyscall really sucked for me
<kristate>
it feels like a hack, and that's why I feel push back from you
<andrewrk>
it sounds like we're on the same page
<kristate>
but at the same time, and what is cool about zig, is that it's very exacting
<kristate>
so, even though it's a usize at the end, you have to cast it from a pointer or from an int
<andrewrk>
I did notice that - that makes sense
<unique_id>
andrewrk: If integrated GPUs weren't a thing I'd agree with you that maybe we shouldn't even think about GPU rendering. However, in the age of heterogeneous computing and integrated GPUs, everyone's principle (Microsoft, hardware vendors, etc) should be to make it as easy as possible to access efficient hardware for our use tasks, and as programmers our principle should be to make proper use of the hardware made available to us.
<unique_id>
we're just missing an easy way to access that juicy hardware! Maybe vulkan is the answer.
<andrewrk>
kristate, did you see my suggestion to directly use the C library from macos-specific code, directly use the linux syscallN functions from linux-specific code, and to make a per-F_CMD abstraction when you need it in code that is shared by both?
<andrewrk>
I think it would be good to start from the code you're trying to write, and then do the abstraction later, rather than the abstraction first
<kristate>
andrewrk: yes, but that sort of goes against the idea of a std lib
<andrewrk>
yes, but we'll get there
<kristate>
if you don't like varToSyscall, I will wire-up that code inside of fcntl
<kristate>
and if we use it in more places
<kristate>
then we can take that out into varToSyscall
<andrewrk>
that makes sense to me
<kristate>
zig highlight says: Focus on debugging your application rather than debugging your knowledge of your programming language.
<kristate>
I think that if we have os.posix.fcntl that it will be simple enough for everyone to use
<andrewrk>
kristate, if you make a PR with a working UDP server or TCP server that has nice tests, it's going to get merged, regardless of how you integrate with fcntl- if I see a better way to abstract it, I'll do it when I merge
<andrewrk>
I'm not going to stop your forward progress
<kristate>
I will knock-out varToSyscall and integrate it into fcntl
<andrewrk>
but if the PR is just fnctl, it seems like you're trying to figure out the best way to abstract that particular thing, so then the API of fcntl becomes the focus
<kristate>
andrewrk: thanks Andrew -- I have some good surprises in store for you. I have been talking to alot of people about zig here in Japan.
<andrewrk>
exciting!
<kristate>
okay, I need to get some work done in this meeting. brb
<andrewrk>
ttyl
<andrewrk>
unique_id, that makes sense to me. and for a music studio, it further makes sense that you'd want to use the GPU for anything you can to free up CPU for audio processing
<andrewrk>
kristate, btw, async-fs is nearly good enough to merge - just a couple bug fixes
kristate has quit [Remote host closed the connection]
kristate has joined #zig
<unique_id>
andrewrk: I need to backtrack on my statement. The thing is I've never known how efficient 2d/UI rendering on the CPU is, and there's this that's coming out any day now (please look at this): https://blend2d.com/
<andrewrk>
ooh event based environments
<unique_id>
that thing is going to be insane
<unique_id>
it'll be open source
<unique_id>
so you can imagine how much easier it's going to be to use this
<unique_id>
well, ported
kristate has quit [Remote host closed the connection]
tuckerkevin has quit [Quit: Leaving]
<unique_id>
but the CPU can't win this battle as the resolution of the monitors increase. I hope they do stop at 8k though, or 4k.
kristate has joined #zig
<andrewrk>
unique_id, I predict the limit will be determined by VR
kristate has quit [Ping timeout: 240 seconds]
kristate has joined #zig
<scientes>
dies zig have VLAs?
<scientes>
on the stack
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
mahmudov has quit [Remote host closed the connection]
<andrewrk>
scientes, nope. it used to but I removed them
<andrewrk>
I recommend determining the maximum amount of memory required and using a fixed length array
<scientes>
on 64-bit platforms there is no shortage of addressing space
<scientes>
although you still can't free stack memory
<andrewrk>
one of zig's design goals is to make it possible to have a statically determined stack space upper bound
<andrewrk>
in addition, certain things should not have the possibility of failure, and have deterministic performance: for example calling a function (and hence using more stack space) must not fail/crash, and must not trap, causing non-determisistic performance
kristate has joined #zig
<scientes>
ahh deterministic performance is a real issue there, i can see that
<scientes>
the others are turing complete issues
<scientes>
cause the performant way of handling stack overflow is to trap SIGSEGV with a guard page
<scientes>
(which java does, but not go)
<andrewrk>
but if your function call traps, that function call is now slower than it otherwise would have been
<scientes>
yes
<andrewrk>
and if you relied on the timing, then that is a problem
<scientes>
you can still have a way of guaranteeing available stack space...
<scientes>
alot of the hash collision issues were just papered over, and should really switch to uses balances search trees with untrusted input
<scientes>
I guess the new hashes are quite a bit better however
<andrewrk>
kristate, I'm staying up late, trying to merge async-fs before bed
<kristate>
andrewrk: cool, yes if we get async-fs out then I can rapidly get UDP and TCP out too
<kristate>
it has been a moving target, but I am excited. We're about to get a stable async foundation.
<andrewrk>
I need to make one more adjustment to cancel semantics
<kristate>
scientes: my company is currently rewriting our core software product (a new internet suite) into zig and we could use a hand. I see that you are interested in crypto
<andrewrk>
but don't worry I'm not gonna hate the messenger
<MajorLag>
I'll have to see if they're all really the same issue or just coincidence.
<MajorLag>
They seem related
<andrewrk>
scientes, you are guaranteed that loads/stores won't move across an atomic operation (at least one with SeqCst)
<andrewrk>
that's pretty much the only guarantee you get about loads and stores with regards to concurrency
<scientes>
but I still have to assure there is a load at all, cause in C that load can be put outside the loop
<MajorLag>
4...
<scientes>
so i think I need builtin.AtomicOrder.Acquire
<MajorLag>
nevermind, back to 3
<andrewrk>
MajorLag, godspeed
<andrewrk>
scientes, you can use @atomicLoad
<scientes>
yeah thats what i'm doing
<andrewrk>
@atomicLoad (at least with SeqCst) is guaranteed to not move across any other loads/stores
<MajorLag>
andrewrk, one of these might not be a bug, but is confusing. Should maybe be considered an enhancement. Basically, if you call a function that uses all comptime-known values, with a comptime-known parameter, it should be able to evaluate to a constant expression, shouldn't it? yet you need to specify `comptime` at the call site.
<MajorLag>
and now that I know why it wasn't working, I can work around it by copying the slice to an array before passing it back.
qazo has joined #zig
qazo has quit [Ping timeout: 276 seconds]
very-mediocre has joined #zig
<MajorLag>
Hmm.. seems like it is not really possible to pass an `fn(type)u8` to another function at comptime. You can @ptrCast to/from *void, but then it explodes when you call it.
very-mediocre has quit [Ping timeout: 252 seconds]
MajorLag has quit [Ping timeout: 276 seconds]
<andrewrk>
that's fixable
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
noonien has quit [Quit: Connection closed for inactivity]
davr0s has joined #zig
<andrewrk>
I have decided that self-hosted compiler (stage2) is not a realistic goal for 0.3.0 (scheduled for sept 12)
<andrewrk>
and I have decided that windows stack traces and macos stack traces are important for 0.3.0
<andrewrk>
I don't want zig to be accused of being "linux-first"
ft3 has quit [Ping timeout: 256 seconds]
<andrewrk>
also, I'm going on vacation tonight. spending 1 week with my family. I might have time to merge PRs and respond to issues, but not much else.
<unique_id>
That sounds like a smart choice. Have fun on your vacation.
unique_id has left #zig ["Konversation terminated!"]
<shodan45>
(under "modify an array")
<MajorLag>
mnoronha: see: zig --help, look for --libc-include-dir and similar
<MajorLag>
shodan45: i is an automatic index for the for loop, it is usize. it has to be explicitly casted to i32 because i32 doesn't wholly contain the possible range of usize.
<shodan45>
MajorLag: ah ok, interesting. Haven't come across usize yet.
<MajorLag>
on debug and release-safe builds, the int cast asserts that i will fit in i32, in release-fast it is compiled out and if i somehow exceeded an i32 you'd get undefined behavior.
<MajorLag>
usize is in the primitive types section, it is an unsigned integer that is the same size as a native pointer.
<MajorLag>
(so u32 on 32-bit, u64 on 64-bit).
qazo has joined #zig
<scientes>
anyone used zig on avr yet?
qazo has quit [Ping timeout: 256 seconds]
MajorLag has quit [Ping timeout: 240 seconds]
qazo has joined #zig
<mnoronha>
Cool, everything works now (I didn't have to point to a weird location for my libc, just made it un-weird)
MajorLag has joined #zig
qazo has quit [Ping timeout: 260 seconds]
<scientes>
is there a way of getting arguments without using libc?
MajorLag has quit [Ping timeout: 272 seconds]
MajorLag has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]