Skip to main content

Nouveau Summer Project : Pdaemon -> Host & Fermi Scripting Engine

I had known and was warned that once I start working on this, there will not be a definitive end. I guess after some time you need to put a stop, just so that you can move on to the next phase. This post will mark the end of X.Org EVOC program and begin my journey as a Nouveau contributor. 
The second phase of the program has been a rather complex one and filled with unexpected hurdles.  

Many changes had to be introduced to command submission algorithm, that we had thought was fit to be implemented. The new implementation after testing proved to work almost completely bug-free.

Probably the most glaring difference would be the omission of 'memcpy' and 'wrap_around' functions.
The 'memcpy' performed a simple a task of copying a fixed length of data from a given location to another specified destination. It took three arguments, namely source, destination and length. This simple function however had a very basic problem. It did not account for the wrapping around ring buffer and hence was not compatible. To fix this problem, a new totally new function has been introduced named as 'memcpy_ring'. The 'memcpy_ring' takes five arguments. Three of the arguments are the same as 'memcpy' namely, destination, source and length. However, two new arguments which have been introduced are ring_base and ring_size they account for wrapping around ring buffer. ring_base specifies the starting memory location on the ring buffer and ring_size specifies the total number of memory locations on the ring.

The 'Wrap_around' function is more or less the same and performs the same task as before. The main difference which has been introduced it that has now been implemented as a macro rather than a function.

The next step in the process was to design a brand new ISA. The ISA meant to serve a primary purpose of being able to successfully execute scripts on pdaemon. These scripts would be of a nature that would provide an easy way to achieve memory re-clocking.

As the first step, the existing HWSQ was studied carefully and an encode_decode implementation was done in C. This not only helped achieving a similar implementation for FSE [Fermi Scripting Engine] at a faster pace but also made understanding HWSQ
To design the ISA [FSE] the following functions were targeted :

  1. Delay
  2. MMIO Write
  3. MMIO Mask
  4. MMIO Wait
  5. Send_msg / Pdaemon -> Host
Even though I tried to design the ISA myself and spent a lot of time troubling myself to be able to do it, I was unable to. I believe I was not up to the challenge of doing so. Luckily enough mupuf had foreseen this and already had a basic layout. He took out sometime and we had a complete version of the ISA. The ISA reads as follows:

The implementation was a three step process or basically producing three files:

  1. FSE.h
  2. FSE_encode_decode.c
  3. FSE.fuc
This final FµC implementation would then be merged in to pdaemon.The first two were similar work to that done in HWSQ. These two files should be referred to understand the working of FSE and can be found as follows. After the completion of FSE.h and FSE_encode_decode.c , the logical implementation was in place and working. This left FµC porting of the code as the next major step which would finally be implemented as a part of Pdaemon.

FSE.h - 

FSE_encode_decode.c - 
The FµC implementation seemed rather straightforward at first but after the initial commit and testing, I ran in to errors. It came forward that I was trying to access unaligned memory locations. Realizing that the existing load 'ld' command was not sufficient, a new set of functions were implemented. A group of three ld_XX functions were implemented in FµC. The ld_32, ld_16 and ld_08 for 32bit, 16bit and 8bit loads respectively:

The current implementation of FSE in FµC looks as follows. This implementation is still under testing and has not yet proved to be in a completely working condition. I should be able to gather enough time and submit a final patch to PDAEMON with a successful implementation while at XDC or as soon as I return.


Popular posts from this blog

Charting API for Financial Markets - JavaScript (SVG)

A brief about the released version of this API is available here.

As a part of the last semester of my graduation program (Bachelor of Engineering in Information Technology), I have been interning with a start-up, namely uTrade Solutions.  uTrade™ Solutions is a financial trading technology company with various products including multi-asset trading platform, algorithms and analytics. Instead of walking through my experience of working in a start-up, I would directly move to a short discussion about my project. 

uTrade Solutions is working to develop a financial analytics portal and every financial analytics portal employs the use of advanced charting. To draw and display different types of charts on the web, there are two main options which are widely used and acknowledged. Namely, Adobe Flash and Scalable Vector Graphics (SVG) . 
Using Adobe Flash has two main disadvantages: It requires the installation of an additional plugin to run content on the browser.It is not compatible with a…

KDE - Authors //Promoting book writing in KDE

If you are in any way related to KDE even if you are just a user and think you can/want to help/join us then without giving a second thought fire an email to me. (

How it all began . .

Last October, Google invited proposals for a GSOC Doc Camp Sprint. The sprint was organised at their offices in Mountain View, California and luckily a team of KDE-Contributors got their proposal selected (I was one of them). Over there, we were teamed up with independent volunteers who were basically professional editors and were briefed about the whole plan. The layout was simple, we had to spend the first few hours outlining the chapters and target audience for our book, then spend the rest of the sprint working on the content. We had proposed to work on a beginner’s guide to KDE development, for developers. Most of the content required by us was available on the wiki but writing a book is a totally different approach than writing a wiki. Working 12+ hours a day , things were on w…

FusionCharts Automated Testing Tool

While working at FusionCharts, every release we were faced with a daunting task of black box testing. Daunting mainly because of the breadth and the depth of the product. This post talks only about black box testing. FusionCharts Product as a whole contains about roughly 90 charts and each chart can be visually tweaked with a set of about 300 chart options/attributes. Ignoring any further permutation and combination, we have right there around 90*300 test cases. Apart from chart options, api testing which consisted of events and methods was needed. Clearly automation was required, as our manual testing would cover only a very small sample set that too based on smart assumptions.

With this problem at hand, I broke it down as follows:
Headless Browser
- Visual Regression
- API TestingUser Browser
- Visual Regression
- API Testing We liked to call it the FusionCharts Automated Testing Suite.

Headless testing would be based of a headless browser and integrated in to our nightly builds. It was…