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.

Month 1 - Part 2

Over the past couple of weeks I've been working on a Vulkan issue that could happen if the user had Vulkan tooling installed that was on a lower version of the API than their drivers claimed they could support. I figured this out when I tried to build the project requesting Vulkan SDK v1.3.296.0 while my drivers supported 1.4+. The error message I got was:

VUID-VkDeviceCreateInfo-pNext-pNext(ERROR / SPEC): msgNum: -1876993556 - Validation Error: [ VUID-VkDeviceCreateInfo-pNext-pNext ] | MessageID = 0x901f59ec | vkCreateDevice(): pCreateInfo->pNext chain includes a structure with unknown VkStructureType (55). This error is based on the Valid Usage documentation for version 296 of the Vulkan header. It is possible that you are using a struct from a private extension or an extension that was added to a later version of the Vulkan header, in which case the use of pCreateInfo->pNext is undefined and may not work correctly with validation enabled. The Vulkan spec states: Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid struct for extending VkDeviceCreateInfo

Which basically means "I don't know what VkStructureType (55) is because it's not defined on this API version."

I eventually figured out that we were chaining feature structs up to the highest available version the users machine could run instead of what we intend to target. I fixed this by choosing the minimum version between what we intend to target and what the driver supports and then using this as a check before chaining feature structs. The code snippet for this is below:

1. We get the device properties so we can see which API version our graphics drivers support

2. We check this against our requested API version and take the minimum

3. We use this as a gate for feature chaining so we don't chain anything over the requested API version

That's all of my updates for now!