[GSoC 2017] 3D Hardware Acceleration - Weekly Report 1
My previous blog post was a brief introduction to my project - 3D Hardware Acceleration in Haiku. The second week of GSoC demands the second post and so here we go.
Well, there hasn’t been a lot of coding work in the last two week, as much as I would have liked, primarily because I wasn’t well for a couple of days. But, I did do what I am supposed to do at this period, i.e. “Bonding with the Community”.
I was regular to the IRC before GSoC started, so I was already familiar with the names. Last two weeks I came to know the people even better. Adrien (PulkoMandy), Fredrik (tqh), James Taylor (Duggan) and Alex (kallisti5) have helped me a lot, among others. I also made friends with my fellow interns - Akshay (akshay), Anirudh (anirudhm), Ayush (a-star), Deepanshu (digib0y), Hy (ugen) and Joseph (return0e). Good luck to all of them.
I started off, thinking of trying to generate an include dependency graph (every node in the graph represents a header/source file in the project and every directed edge from file1 to file2 indicates that file1 has included file2). The motivation was if I could generate such a graph, then I could easily move up from the leaf nodes to the highest-connectivity node in the graph, without breaking the compilability of the source. I tried to generate the graph using Doxygen, running it on DragonflyBSD’s sources.
It looked good for some files, like drm_atomic.h shown below.
But it failed for drm_auth.c (drmP.h has a fairly large list of dependencies, which I expected to see in the graph, but unfortunately did not).
I asked people on the mailing list for help, and surely enough, received a lot of it. PulkoMandy suggested some more tools, but none of the seemed to work the way I wanted them to. At last, on PulkoMandy’s and Duggan’s suggestions, I decided to add files to the source and rely on the compiler generated error files to proceed.
I have set up the development environment. The Jamfile for building DRM is ready and populated with the files required for DRM. The way I am moving forward from here is as follows:
- Uncomment a file in the DRM Jamfile, so that an attempt is made to compile it.
- The compiler complains about some missing file.
- Try to add the missing file to the source tree.
At some point, when everything actually compiles, then we will start the testing phase, as successful compilation does not mean everything will work.
Hamish Morrison (hamishm) started working on DRM Drivers in Haiku about 2 years back. His repository has been the starting point of my work. Duggan integrated hamishm’s work into his fork of Haiku’s latest code base and cleaned up a few files. I wanted to take things one-file-at-a-time. So, in my fork, I started adding the source files and headers that are absolutely required for DRM one-by-one from Duggan’s repo and DragonflyBSD’s Linux Compatibility Layer, tweaking them as required.
You can track the changes I make by looking into the ‘drm’ branch of my fork. I have just started with this iterative process and I do not expect it finish quickly, but the effort is being made to be done with it as quickly as possibly, the road ahead is long.
- [GSoC 2017] Porting Swift to Haiku - Week #1 / #2
- [GSoC 2017] Preferences GUI Refactoring - Weekly Report 1
- [GSoC 2017: Harfbuzz] Week #1 #2 of Community Bond
- [GSoC 2017 - BTRFS Write Supports] Week #2
- [GSoC 2017] 3D Hardware Acceleration - Weekly Report 1
- [GSoC 2017] First two weeks of Community Bonding
- [GSoC 2017] Porting the Swift Programming Language to Haiku
- [GSOC 2017] Tcp optimization and fine tuning
- [GSoC 2017] Adding write supports for Btrfs
- [GSoC 2017] Calendar Application