Month 3 - Blog 6 - Gateware Development

GNodeFactory... a factory to manage large amounts of nodes.

An initial task that was started throughout these previous weeks was to implement most of the Get and Find methods regarding GNodeFactory. Without these methods being implemented the developer or user will not be able to actually retrieve information in the system. Say they lost a child node's handle, without the methods getting the handle back easily would become a lot more difficult. That being said the following methods were implemented to help provide this functionality: 

• GetImmediateParentNodes
• GetImmediateChildNodes
• GetImmediateSiblingNodes
• GetFactoryInfo
• GetFactorySize
• FindAllParentNodes
• FindAllChildNodes
• FindAllSiblingNodes

This grouping of functionality was fairly straightforward with its approach. Simply access the pool, then access the state of the given node. Repeat for the number of requested nodes. This takes into account that all the data has been validated beforehand. Since swapping to using a GNodeHandle it makes determining the pool and node a bit easier since they are in a union as an unsigned long long. 

Finding the nodes however was a little bit more involved since it required using a DFS Traversal to gather the nodes. Since the user might not know the amount of parents or children that a node could have, the number of nodes gathered is also given as an out parameter. Traversal can get a bit cost heavy, to avoid this there is a thread_local vector maximized to the number of possible nodes we have. This way we will never run out of space to allocate nodes and there is always enough space to fit all existing nodes in it. For FindAllChildNodes, siblings are pushed onto the stack first, then children. Since it's a stack, children come out first when we popped, which helps with traversal since they are still in order.

Aside from the Finding and Getting, in a previous meeting Lari pointed out that AllocateNodes didn't properly allocate to the right pools. Embarrassing as that was, he suggested to use a GPool Structure which was similar. Instead of having 4 pools (states, metas, internals, and nodes) there would be a single factory of GPool. So instead of trying to manage both data oriented and parallelization. We shifted to 100% parallelization and attempting to maximize the efficiency of that. 

Allocation was adjusted to create a pool of an ideal size (currently 4096) and push nodes into those pools if there is room. If the user asks for a larger count than 4096 then a pool of that size is made. Otherwise if there is room found in an existing pool to use that, or make a new pool of ideal if none is found.

GHandle also was introduced to help identify nodes and pools properly. Instead of the node and pool being individual memebers, they are now a union as a "handle" which can be passed as an unsigned long long. This makes it so the user can store handles quicker and easier for the end user/developer.

The next milestone will be nearing the end of GNodeFactory's development time with me as I hope to implement the Resolving of the Hierarchy and a visual demonstration of it working!

Month 3 - Blog 5 - Gateware Development

 These last two weeks have been quite hectic to say the least with Gateware. As development continues with GNodeFactory (GNF) a couple of hurdles came along. First was how to actually store the data within GTL's Factory architecture since I was still getting the hang of it. GNF is supposed to be structured as a factory containing multiple root factories. These root factories will help manage threads and computations making operations faster than single threaded executions. I initially was not able to fully grasp how the implementation would look, but after some time with a single root factory I slowly was able to understand and created the below implementation so far. Previously there was going to be a pool for the State and Meta information in their own factories as well, but after discussing some storage and accessing viewpoints with Lari we decided it was optimal to keep the information within the Internal Node structure. This makes looking up the information faster since there is no need to perform additional access operations. 

This led into the next task for implementing allocate and deallocate for GNF. Whenever Allocate is called, it will attempt to recycle an existing pool identifier before creating a new one. With this design I choose to create a pool of root nodes wherever is available first. Deallocating performs the inverse by validating the data is available to remove then cleans up any associated data pools and recycling their identifiers. Since this task was done in the previous week portion for this blog post, I have now code reviewed and merge requested the Allocation/Deallocation of GNF with Lari.

Moving forwards to the bulk of this previous weeks work: Parenting and Unparenting. There were some challenges at first to Parenting and Unparenting, first was making sure the calculation was one with the proper inverse performed on the parent nodes rotation. One issue that I found while writing the unit tests was that if I wanted a duplicate index to unparent then the operation should technically fail since I shouldn't be able to unparent an already unparented node. Provided that most of the implementation still stays relatively the same, I believe Parenting and Unparenting are nearly complete as of this post being written.

This milestone also covered reading and writing to the nodes, matrices, and meta data while keeping reading of the states non-writeable. State information regarding the nodes would be purely manipulated internally since there should be no reason to modify a parent/child/sibling/depth/flags associated within the nodes. Unit tests to validate that these operations are performing as suspected are also being written since validation and unit tests are required for very part of Gateware.

Moving forward into the next two weeks I will be focusing more so on implementing the resolving of the hierarchy and ensuring that all data within GNF uses the flags properly. There will be many.. many more unit tests to cover with more implementations and samples near the end of that.

Month 2 - Blog 4 - Gateware Development

Over the past two weeks, I have worked on getting the new GNodeFactory library set up and having a basic skeleton structure with boilerplate implemented. An initial work item for adding the initial GNodeFactory boilerplate files was made. Within it, the Universal/Dummy Implementation, Class Header, and Unit Test files were all incorporated. Since most of the functionality within GNodeFactory is shared between the floating and double precision types they can exist within a shared implementation class. A few structures needed to be added within GMathDefines being the GNode, GNodeState, and GNodeMeta. Each of these structures will help manage the basic information required within the factory. GNode will contain the transformation/rotation/collision information. GNodeState would incorporate how to traverse the hierarchy with access to the parent, child, and siblings. Lastly, GNodeMeta data will be utilized for future libraries within Gateware were the data can be managed by downstream systems.

Since GNodeFactory is part of Gateware it also requires Unit Tests to be made using the Catch2 API as all previous libraries have. For the Unit Tests I wanted to make them clear as to what functionality I would be testing with descriptors of the precision type. Some prior libraries use the SECTION macro to differentiate tests, so I opted to also use that with distinguish precision.

Lastly, I have been working on a spike solution for GNodeFactory as I wait for Merge Requests and Code Reviews to take place. I have made some significant progress with the spike solution as I was able to get some users to test out the work in progress library and give some feedback. The spike solution is a significantly condensed version of GNodeFactory but aims to stick as true as it can to the goal of the library. Within the spike solution I am opting to use return types instead of pass by references/pointers which Gateware utilizes. This is for simplicity on what the library will do in the meantime. Below are some implementations of the spike solution:

As we get into the next couple of weeks I will aim to implement the spike solutions research into the GNodeFactory library itself. Currently awaiting code reviews and feedback from maintains, advisors, and instructors. 

Month 2 - Blog 3 - Gateware Development

Another two weeks have past and that means another blog update. This time with progress not only on the GSample repository but also the GNodeFactory implementation. Some of the samples I have worked on in the past two weeks were:

• GFile
• GLogic
• GBlitter
• GController
• GInterface

Most of these samples will help when it comes to unit testing for GNodeFactory since stress testing the library will be conducted over a period of a week. This will need to involve automated data analysis which GFile and GLogic can help assist with. GInterface will be utilized (Specifically GInterfaceInterface) within GNodeFactory to inherit functionality helping manage the libraries lifetime and tasks.

GBlitter, while unable to really assist with GNodeFactory itself, has reinforced the concept of descriptive code. That will help me make GNodeFactory as understandable as possible for users. The GBlitter sample features a slime sprite spinning around on some grass tiles. By using TGA files, GBlitter can import and have the tiles defined. 

I have also made progress with drafting more of the official proposal out. A section stating the allocation and management of nodes is still to be written but will be accomplished before the next milestone. I have started to implement the interface for GNodeFactory within the source. Since it is a math library it will utilize both Float and Double operation types. Also since this library is in progress it will be marked with the "In Development Flag".

Month 1 - Blog 2 - Gateware Development

 The past two weeks have been hectic to say the least. Being filled with development and preparing for my presentation, my nerves were definitely on the line. Since my ongoing task was to create samples for the new GSamples repository, I added some more tasks for samples expanding on the following Gateware modules:
- GMatrix
- GVector
- GQuaternion
- GDaemon
- GThreadShared
- GConcurrent

So far most of theses samples have been merged into the main GSamples repository which is very exciting. They didn't come with the fun hiccups of learning more about CMake, like with GAudio and GBufferedInput, but did offer more learning into how threading and concurrency work. 

Developing GDaemon's sample created an interesting point about the documentation provided in the Gateware Doxygen resource. My assumption was to make a daemon, then add event responders to the daemon. This ended up not being the intended functionality and needed to be swapped out for something more focused on GDaemon itself. Swapping to demonstrate the Fibonacci Sequence using a daemon seemed more suitable, so one daemon was used to run iterations of the sequence while another toggled the sequence daemon on and off. Both of these daemons had event responders to print out the status of the daemons, while also running at specific intervals.

The rest of the samples went smoothly, with little to no issues arising. This helped the fact that I had to work on my GNodeFactory Proposal Presentation. This was a requirement of the CSMS degree in which I had to get the project approved by the Committee members. The past week I worked with Lari to present my materials to the Gateware Maintainers, which was insightful. They provided a ton of feedback which I tried to incorporate as best I could into the upcoming presentation. After the meeting with Lari and the maintainers, I had my meeting with the Committee. They really liked the project and were interested in a ton of the unit testing and research ideology. Overall I think the past two weeks have been really fun, not only for my confidence, but for learning more with modern systems.

Month 1 - Blog 1 - Gateware Development

So being onboarded into Gateware was fun to say the least. My tasks for onboarding into Gateware were simple at first, recursively clone the repositories and verify they build. Since I have a dual-boot machine I can test Linux (Ubuntu) and Windows implementations fairly quickly. Mac on the other hand wanted to cause a bit of trouble by not being updateable. After eventually getting the required software installed and validated everything was cloned properly, I started working on the GSamples. 

GSamples is a new repository that aims to help developers who are unfamiliar with how Gateware operates into showing how to utilize the library. There were some samples already provided such as the GVulkanSurface and GOpenGLSurface which helped give me a jumpstart into what was expected. The first sample I was to work on was for the audio interfaces GSound and GMusic. As I started to make the samples, I found that isPlaying wasn't implemented into the main API which was what I used to identify if the sample should stop or continue playing. Since the Audio Interfaces needed a running application to continue playing the sound, this created a bit of a snag. Though thankfully Alex Cusaac mentioned opting to use sleep_for and yield instead. 

So safe to say I was out of the clear for the time being. Turns out testing all available platforms is really important. The audio I happened to use for the sample had a formatting issue which exposed an underlying offset bit read in the GMusic implementation. With that fix pushed, I was able to continue validating the GMusic and GSound samples. These samples helped me understand how the Gateware Developers use a Continuous Integration / Continuous Development (CI/CD) Pipeline to always test and push updated releases.

While I wasn't familiar with CI/CD I have grown to like this format of development. The next couple of samples I worked on were GInput and GBuffered Input. Since I wanted to print out the ASCII equivalent of the key pressed, CI/CD allowed me to pull the latest version of Gateware and implement that fix. 

My future work with Gateware will be to inevitably incorporate the GNodeFactory module. This module will help manage large 3D Transformation Hierarchies like scene graphs. For now I am researching into how I can parallelize and optimize operations in the factory before implementing them. To accomplish this task, I was requested to look into GConcurrent, GThreadShared, and GDaemon. These modules in Gateware are also on the coding chopping block for samples to create. Additionally GVector, GMatrix, GQuaternion are also going to be implemented over the next two weeks. 

Month 2 - Part 1

Over the past week I was working on a Vulkan validation error that was caused by some weird environment setup on my machine. The error was complaining about not knowing what a specific struct type was when chaining features on in our CreateVkDevice() method in this section of the code:

What was happening was the requested API got set to 1.3 but 1.4 was defined so when it would hit the #if defined(VK_API_VERSION_1_4) it would try to chain on the 1.4 feature struct but was using the 1.3 validation layers which were too old to recognize this newer struct.

Validation layers in Vulkan are meant as a debug tool to tell you when your pipeline/set up is off and helps debug issues early before they become a problem in release. Despite the message, everything got set up correctly and I couldn't reproduce the issue reliably so Lari and I decided that it would be best to move on as it was probably a user error in how I set up the project and my environment variables.

I then moved on to an issue reported to us by Justin Edwards:
VUID-VkDeviceCreateInfo-pNext-02830(ERROR / SPEC): msgNum: 555635515 - Validation Error: [ VUID-VkDeviceCreateInfo-pNext-02830 ] Object 0: handle = 0x25a8407cc70, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x211e533b | vkCreateDevice(): If the pNext chain includes a VkPhysicalDeviceVulkan12Features structure, then it must not include a VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_FEATURES structure

Which is complaining about 12 including the VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_FEATURES structure which comes from this part in our code:

Where before we didn't have the:

#if defined(VK_API_VERSION_1_2)

features12.descriptorIndexing = VK_TRUE;

#else

but with the new if define we're basically saying if we're on 1.2 or higher then we don't want to add that flag which ended up fixing the issue.

To ensure this fix was working we asked Justin for his exact setup and I created a test case mimicking this which looks like:

Which also accounts for the other versions of Vulkan. This test reproduced his errors without the fix and didn't produce them with it which proved our fix was working. He then downloaded the new Gateware version and tested it, confirming that it cleared that error but still produced this:

I'll be looking into what's causing this validation error along with tackling these tasks:

Which should provide some good learning opportunities for me.