Comparing Vulkan and D3D12

Recently I wrote the PetitD3D12 to extend my graphics API knowledge to the land of DirectX, well I am surprised to see how similar those modern graphics APIs are. More precisely I think Vulkan is trying to stay close to D3D12 these days for be able to easily translate it. However there are also some noticeable differences, surprisingly I did not find too much “real” API comparison info, the Alain Galvan’s blog post are more just about grouping those API data structures together, not much you will know the difference in using them.

Wayland client side window decorations through libdecor

I have been away from wayland system for a while because of work, but I still remember back in the day the pain to manage the window frame (as known as decorations) in wayland system. Surprisingly quite a lot of server work shifted to client side to manage, eg, you need to implement key repeat event in the client applications. There are two ways right now to do the client decorations.

Moving towards GPU driven

We were using a traditional for_each style drawing G-buffer and shadow in Vulkan, with over 2.5 million triangles, and 25,000+ objects, I started to see my GTX 1650 having hard time following it up. Although you can pre-record command buffers in Vulkan to reduce the CPU time but we will also end up with a very large command buffer to submit and potentially miss the driver optimizations with indirect draws. These days, GPUs are getting more and more powerful and complex, including tons of new features.

Comparing Vulkan Frameworks

There are indeed many people tried to implement a rendering framework on top of Vulkan to reduce the amount of code to write. But so many of them merely just create a wrapper around existing Vulkan objects, like wrapping the command buffer with a vk::CommandBuffer::Ptr and you still have to fill all the VkObjCreateInfos . The rendering framework focus on the render passes should provide a compact yet descriptive API to create render pass.

Moving to Hugo, Aftermath

My blog is now back online, with brand new render engine Hugo. The URLs are totally different though. Not sure how web crawlers handling it right now. After the migration, I did a few extra work for patching the hiccups. Fix the build warnings and adding new features. The about page In every blog you always have some pages that you do not want it be inside the blog list. By default Hugo will simply place everything on the “navigation list”.

Moving to Hugo

For a long time I’ve been wanting to Migrate my blog system from Pelican to Hugo. One reason is that I had enough with python virtual environment breaks every 3 months. Another motivation is obviously I would like to replace Python with Go in my life. A long time ago I followed Go tutorial for getting started, surprised by its syntax tidiness and similarity to Python, and it is way faster.

Belief or Cult

It’s been a while that I haven’t update the blogs. It is so easy to slack off on good habits. “Oh I will continue once I finish A B C”. We are all busy as hell, in the software world, you WORK, you WORK and you GO TO SLEEP. Like this one, I am always hoping to switch to Hugo, then I can continue writing the blog. The thing is, I never got the good weekend to do the switching.

July 2021 Status Update

I am now back in Canada, quarantined again. There is much of internal struggle whether I should move back or stay in Shanghai? Working for tech company in Shanghai or many cities in China would be like endless crunching. Maybe I was not used to this high-paced lifestyle, long working hours. Didn’t like javascript either. It is a pity that I didn’t find a nicer job maybe opens to better opportunities.

Scalable org file synchronization solution

In my previous post, I’ve somewhat found a way to synchronize my org files. I was pretty happy, I was having just around six org pages, coping them to a webdav server was not a huge hustle :P, util I started to use org-roam. Suddenly I have to create org file for every new zettle, the performance quickly started to tank. This is probably the beauty and curse of using open source solutions — you have full control of your work and you have to solve problems you created yourself.

The sphinx website for your project

Static site generator, I love and hate them at the sametime. They really render your markdowns into a beautiful website without need of knowing web technologies. Then there are the constant hustles once you try to customize it, change a theme, adding different functionalities or upgrade. It is YOUR website, you want it look different than others, right. At some point, whether you like it or not, the SSG users will take the role of website designers by tangling with CSS.