Cieric

The only place I see that is from a user "LiEnby" not "aletik", and none of aletik's existing messages are edited. All replies I see with the message are also to LiEnby. I don't agree with aletik's slow response in any way, but I don't think your claim is correct either. Do you have anything to prove that this was said by aletik?

Neither did I, feel free to email me or message me on discord and I can try to download the video and send it to you.

Here is a video that I actually just watched recently on that exact thing.

https://youtu.be/jfLAaGtNc7U

I've been interested in doing something similar in the past, but I could really never solve issues like domain squatting and stopping individuals from claiming every name possible. Do you have a place where you keep these plans or have discussions around it? Or even just a place where I could get updates if anything does come of it?

As someone from the US I would suggest viewing both as adversarial. I don't really trust my own government, but if I was born abroad I would trust them even less.

He's avoiding LLVM which is a compiler framework. Not LLMs as has been stated a few times in the comments already.

I don't have a lot of faith there, but that's mainly due to my experience being correcting peoples assumption that all gpus waves are 32 lanes. I might be biased there specifically since it's my job to fix those issues though.

Now that I could agree with, the only place where hiccups have started to occur are with wave intrinsics where you can share data between thread in a wave without halting execution. I'm not sure disallowing it would be the best idea as it cuts out possible optimizations, but outright allowing it without the user knowing the number of lanes can cause it's own problems. My job is the fun time of fixing issues in other peoples code related to all of this. I have no stakes in rust though, I'd rather write a custom spirv compiler.

I'm not even sure a 32 wide array would be good either since on AMD warps are 64 wide. I wouldn't go fully towards auto vectorization with though.

Door knob seems to return a bunch of chess pieces and analog sticks, I did get a few doors and a few knobs, but nothing I recognized as a door knob. I didn't spend a super long time looking though so that might have been the problem there. Also suggestion, giving the ability to link to specific models might be useful (I tried a few things on mobile, url doesn't change and searching for a specific model ID doesn't return the model).

From the last time I looked at these recompilation projects, they take the assembly and basically convert each opcode back into an llvm instruction and then recompiled from there. This comes with a lot of caveats though, last time I looked at it we still needed a function map of some kind to tell us where all the functions are and you still needed to replace chunks of the generated code afterwards for things like rendering, sound, controller input, and just about anything that would interact with the world outside of the cpu.

Edit: After some reading on the github page, it seems they are translating it to c++ instead of using llvm directly, but the original idea still holds. They aren't decompiling it to c++ that looks like original source code, it more like they're converting it to c++ that emulates the processor and gets statically compiled.

So it's not really just a drop and go replacement like it sounds like it'd be, but it has so far enabled the recompilation of multiple n64 games. This seems like an extension into the ps2 space.

Side note: The ps2 is a 32bit console with a 64bit alu (and some 128bit simd)[1]. So a lot of the weird tricks from the 8bit days weren't really used here. Not that there aren't weird tricks, just things like using undocumented instructions and racing the beam are less prevalent. I could be wrong here, I was growing up at this time not making games. All of this is just from research I've done in the past. Someone feel free to correct me if I'm wrong.

[1] https://en.wikipedia.org/wiki/PlayStation_2_technical_specif...

Well you could already do doom for about 6 months now [1]. I haven't tested the nvidia side, but it ran okay on my RX 7700S in my framework laptop.

[1] https://github.com/jhuber6/doomgeneric

I'm not even sure it's just instruction support that's the problem with the RV2. I bought one since I thought it would be cool to write a bare metal os for it (especially after I found the AI results to be so bad.) But the lack of documentation has been making it very hard to get anything actually up and running. The best I've got is compiling their custom u-boot and linux repos, and even those come with some problems.

I think in this case browser is meant as a place to browse, e.g. the Google Play store is an app browser. I don't hear it used that way often anymore, but it at least sounds familiar.

I'm not sure I'm gonna grab another OrangePi board again. I was happy to grab the RV2 just to experiment around with, but I didn't realize that the linux kernel they provided to build their ubuntu distro doesn't actually build properly. I got it to build after throwing a version of ubuntu onto an unused pc, but then it didn't matter the options I selected for the build (like gui options) it seemed like the gui just didn't exist at all in the final binary. I've yet to try and build a 3rd party os with support since I spent so much time just trying to get the official distro to work properly.

I think you mean MS/AMD since this is for hardware with AMD parts in it.

At this point I'm not sure I can give a satisfying answer, but zig was just fun to use from the beginning. It was just c, but with a bunch of special features like comptime, the lessened foot-gun-ness of zig was just a benefit since most of the conventions were just things I was doing in my head but not putting into the code (since there wasn't really a good way to do so without compromise). The other thing I liked was I could just immediately read and write it without much looking at the docs. Their standard library was a bit of a hurdle, but the fact that the whole thing existed on my disk and I could just pop it open and read the code really helped (I assume this is the same with Rust, but I have trouble reading rust without going to lookup syntax). So while I can't give good reasons for using it in a commercial setting, for personal projects it was just fun. Rust in comparison hasn't really been fun to try and pick up.

At this point however I don't really like the way zig is going. So I won't really advocate for zig at this point, but I can say when I first started using it, it was fun and I could just write code that worked.

Let's not forget about TigerBeetle either. They weren't bought (as far as I'm aware), but they seem to have some pretty good backing from customers.

I'd be careful about that one, there is still no license for it. Zork is notable here since it just got the MIT License applied to it.

I really wish I could like zig more, I started using it heavily around 0.11, but I feel like as more features get implemented there is more that I like and more that I hate.

They've recently fallen into the trap of the wrong whitespace will now error compilation, which has effected me directly.

All the none blocking IO was stuck behind async, which when I was trying to use it it literally didn't exist (this might have changed in 0.15 from the videos I've seen, but all my code fails to compile now do to the former issue with whitespace).

I might come back at Zig 1.0 as long as some of the stupid decisions can be reverted or worked around in some way I find acceptable, otherwise I might just fork it myself to fix it so I can still have some fun with the language.

> It's officially deprecated in favor of Vulkan

Can you provide a reference for this? I work in the GPU driver space (not on either of these apis), but from my understanding Vulkan wasn't meant to replace OpenGL, it was only introduced to give developers the chance at getting lower level in the hardware (still agnostic from the hardware, at least compared to compiling PTX/CUDA or against AMD's PAL directly, many still think they failed.) I would still highly advocate for developers using OpenGL or dx11 if their game/software doesn't need the capabilities of Vulkan or dx12. And even if you did, you might be able to get away with interop and do small parts with the lower api and leave everything else in the higher api.

I will admit I don't like the trend of all the fancy new features only getting introduced into Vulkan and dx12, but I'm not sure how to change that trend.

This looks neat and would probably be cool to run on one of my passive info screens. But until it supports more than just Nvidia I'll have to stick with nvtop. Might be a good idea to pull the theme out to a file so it's all swappable too (assuming you haven't, I can't look at the code right now.)

I've actually been dealing with this myself recently, but only the gpu portion. I've been trying to get a gpu working on the orangepi RV2 just to see if I can. The tools for building the kernel for orangepi are kind of bad though.

But no, the 2 old amd gpus I have just don't show up at all in lspci, testing the RTX 2080 and RX 7800 both did show up though.

True, I think getting a block chain setup in a month is possible. But at the same time I don't think they would try and rush something like this out, stuff breaking would be much worse PR after what has already happened.

I do think it's possible they put more money/talent onto the problem after it happened though.

I wonder if this was initiated by all of the steam and itch.io content getting removed due to payment processor rules. If I remember correctly steam used stripe (at least at one point in time) so it might be trying to get back into that market without being limited by the payment processors above them.

That sounds useful, do you have the Dockerfile for it pushed anywhere?

I think they mean that the number that the image starts on is by default 0, I think they want to be able to change the starting number so top left could start at something else and increment from there. Adding on to that it would also be interesting to change what the number increments by.

Just to add some context Adam works at AMD as a dev tech, so he is constantly working with game studios developers directly. While I can't say I've heard the same things since I'm somewhere else, I have seen some of the assumptions made in some shader code and they do line up with the kind of things he's saying.

Yeah, we also have a gaming and a developer discord where I hang around. So feel free to join and ask questions there.

While I won't endorse what the GP said, I wouldn't say that it's only gotten worse. I work for a modern gpu company (you can probably figure out which one from my comment history) on one of the modern apis and they much more closely represent what the gpu does. It's not like how opengl use to be as the gpus hold much less state for you than they use to. However with the new features being added now it is starting to drift apart again and once again become more complex.