Over a month since making the last post and not much has changed. I'm still packing and getting ready to move. A month seems like a long time to pack, but I still have two weeks before I can even move in to my new place, so I've been taking my time. Then there is the process of cleaning up the house and getting it ready to sell, this ought to be fun as it's my first time selling a house.
Anyway, as far as coding goes I'm still apprehensive on continuing my previous projects. I can't seem to devote much time and energy into them right now or I'll get nothing done around here. There seems to be a lot of visits to this thread, so I'll definitely keep that in mind when I do get back to it.
Below are going to be some notes for me to consider when that time comes. Hopefully, they will be of use to others when that time comes.
- Finish fixing up the tutorial code
- Look for ways to optimize
- Test OOP: The tutorial uses a fair bit of casting to handle the different commands and data payload, I'd like to use std::variant.
- If I understand enough of the process, then perhaps a small tutorial.
- Prune what I don't need for what my original intentions were, the SIMD shader.
The tutorial linked uses a fair bit of casting and dynamic memory allocation, so I'd like to convert it to use std::variant. One reason is no dynamic memory allocation, another is concrete types so no if/else if/else or switch/case branches. As far as I can tell, Microsoft's implementation already uses a switch block to branch to a specific function or to determine what the active object is, so it isn't 100% static dispatch. I think it'd clean up the code a bit as well, and if I do actually make a small tutorial on it, this is what will be included.
I thought over some things regarding the SIMD shader, and I'm not entirely sure what the end result is going to be. For instance, each version of SIMD ( SSE, AVX/2, AVX512 ) has different size and alignment requirements as well as different processor and operating system support.
The hardware and software support I don't see being an issue. I found a bit of code I copied from stackoverflow for that part. The issue is going to be data layout, alignment and register widths.
I want to have mathematical vectors like Vec2/3/4 available as intrinsic types. Now, if I keep them as AoS which is easiest to program in, I have to worry about a Vec2 only taking up two slots of say an 8 slot SIMD register or going past memory boundaries. However, I could convert the data into SoA format when the user creates a buffer. It would be difficult to convert between AoS -> SoA and then back, but with templates or some kind of runtime description I think it'd be possible.
The compilation would be done when you pass in the shader script. The return of that, assuming a successful compilation would be a simd_shader object that stores an std::vector<std::variant<...>> where the ... would be a list of supported commands.
Seeing as SIMD is all math based, I wouldn't need support for functions nor structures, though I think structures would be useful. Another useful feature which is included in the tutorial is first class functions..ie lambdas, so I'll probably keep those in as well.
As a final note to myself, I thought it'd be fun to create a type of software emulated arcade machine or console. Of course, it'd wouldn't be very powerful, but who knows it could turn out some rather interesting programs. I watched a few YT videos about the 6502 processor that was in the original Nintendo and Commodore 64, with all it's limitations and how creative programmers had to be and it kind of inspired the idea.
END OF NOTES
Another big change may be that I actually may have to get a job. Seeing as I don't have much in the way of formal education and with my visual impairment it'll just be a menial one at best. Basically, I won't have a lot of time if that happens, so things are going to be slowed by that as well, but we'll see. Anyway, for those in America, happy Thanksgiving, Merry Christmas and have a happy New Year.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com