There are a couple of reasons why the work hasn't landed yet. One is simply that not all the patches have been reviewed, Arrays of Arrays hasn't been to high on the priority list for other devs, one reason for this is that no games have seemed to use it. However “Middle-earth: Shadow of Mordor” which was released in July is using it in a one of its shaders [1] so we may start to see it pop up elsewhere too.

The other reason it hasn't landed yet is that as each new extension that extends the gl shader language is added to Mesa it can mean that Arrays of Arrays support is needed for that extension too.

The good news is that I sent v5 [2] of the patches for review last week, I also have some follow-up patches that implement a feature required in the spec that both the AMD and Nvidia closed source drivers don't support so Mesa should hopefully soon have an Arrays of Arrays implementation that is more spec compliant than both of these drivers.

I should also point out that while these latest patches haven't landed there have been bits and pieces landing over the past couple of years so there is already partial support in Mesa.

So what's next for me? I've been asked since starting this campaign if I would do another one and for now the answer is no as I will no longer need to. As of November I will be working full time on Mesa for Collabora as part of their arrangement with Intel. I'm really excited about this and need that thank all of you for allowing me to get involved in Mesa in the first place.

One final thing before I go, before being offered the opportunity to work full-time on Mesa I was actually working on a game about Linux as a way to fund my next bit of work on Mesa. Nothing special just a bit of fun with RPG Maker XP to create a game which runs on the open source implementation of the engine. I've had a bunch of great custom artwork done (at my own expense), custom scripts, the story-line is done, and I have a playable demo (start to the game). The thing I don't have as usual is the time to finish it alone, so if there is anyone out there with RPG Maker skills (or pixel/vector art skills) that would like to have a bit of fun partnering up on finishing it of let me know, and I can provide the demo to see if your interested.

That's all for now, as always thanks for your support. Please feel free to leave comments below or email me at the email address you can see in link [2].

[1] https://bugs.freedesktop.org/show_bug.cgi?id=92059

[2] http://lists.freedesktop.org/archives/mesa-dev/2015-September/094652.html

The post Arrays of Arrays Update and Where to from here? first appeared on ITSqueeze.com.

Since then I've slowly learnt more about the xbox controller drivers on Linux and eventually I couldn't help myself any longer, so I dove in to see if I could find a solution.

After it was confirmed to me that Oddworld still freezes on the an updated driver from Valve that is used with SteamOS and fixes other bugs such as always reporting that there are 4 controllers when the wireless adapter is plugged in and fixing the constantly blinking light issue, I turned to giving the alternative xpad360wr kernel driver a go [1].

Once I figured out how to unload the xpad driver and load the xpad360wr driver I tried to use my controller with the new xpad360wr driver on a game that didn't previously freeze with the xpad driver, but now my controller wasn't detected by the game at all.

I recalled seeing a list of id's in the xpad drivers source code for identifying usb devices so I decided to make sure the xpad360wr wasn't just missing an id.

It turns out xpad lists two id's for the wireless receiver:

{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },

{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },

Where as the xpad360wr driver only listed the ids 0x045e, 0x0719 so I simply changed the id and rebuild the driver.

Unfortunately now when I tried to connect the controller my laptop locked up and required a reboot, it seemed like a slight win because at least it seemed to be detecting the controller now. The kernel was reporting some null dereferencing errors with the driver and I was about to contact the xpad360wr developer about this when I thought I'd better make sure that I was using the correct id first.

My plan was simple, build the Steam OS xpad driver and with the 0x045e, 0x0291 ids commented out and if the driver doesn't work with a known working game then that's the correct id and there is a bug in xpad360wr.

However something strange now happened, my controller now worked with Oddworld the freezing issue was gone. I can't explain why its now just working, maybe it's something to do with my receiver being a cheap ebay knock off rather than an official receiver. My knowledge in this area of the operating system is pretty much non existent but I intend to follow this up with the xpad and xpad360wr dev's to see if they can hopefully explain the issue and help solve it properly once and for all for everyone. I may even get to contribute my first kernel patch

For now here is how to build and install your own kernel module to work around the issue.

1. Blacklist the default xpad driver so its no longer loaded.

On Fedora I created the file:

/etc/modprobe.d/blacklist-xpad.conf

And added the following line to permanently disable the driver from being loaded:

blacklist xpad

Then reboot.

2. Download and extract the source for the Steam OS xpad driver:

http://ppa.launchpad.net/mdeslaur/steamos/ubuntu/pool/main/s/steamos-xpad-dkms/steamos-xpad-dkms_0.3.orig.tar.gz

3. Open the xpad.c source file and comment out or delete the following line:

{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },

4. Build the Steam OS xpad driver

In a terminal just type “make” in the directory where you have extracted it.

5. Load the driver you just built by typing the following into the terminal:

sudo insmod xpad.ko

6. Play Oddworld

Note: One thing I did find is the controls are mapped badly but I've read this is an issue with the wired controller also so I'm not sure if this is related to this hack or not. Also I believe you will need to reload the driver each time you reboot, I haven't worked out how to load this automatically yet.

It would be great to know if this worked for you. Feel free to leave a comment below.

Update: I finally worked out why commenting out that line of code caused the controller to work. It causes the driver to use some fall-back code to try and work out what type of device it is. The important thing is it ends up giving the device the name “Generic X-Box pad” rather than “Xbox 360 Wireless Receiver (XBOX)”. So what's happening is the game is checking if the device name contains “Xbox 360” then doing something (I'm not sure what) that's causing the game to break.
This means for those with the other type of wireless receiver you just need to change the name on the other line of code and the work around should work for you too.

Update 2: Using the remapping settings here the game now works perfectly with the patched xpad driver. http://steamcommunity.com/app/314660/discussions/0/611702631211590678/

[1] https://github.com/computerquip/xpad360wr

The post Getting Oddworld: New 'n' Tasty to stop freezing with the xpad driver first appeared on ITSqueeze.com.

Also you don't necessarily need to be a super programmer to identify hotspots in the code and try to come up with a way to reduce CPU as I will hopefully show you below.

Back-Story

Earlier in the year I was reading some bench marking results at Phoronix comparing the open source Radeon driver against the closed source catalyst driver. For some older games like OpenArena the radeon driver was only a small way behind catalyst for most cards but for the higher end radeon cards catalyst started to leave the radeon driver in the dust. Upon reading the following comments about the results in the phoronix forums the speculation was that the open source drivers are causing a cpu bottleneck on the higher end cards. This got my attention so I decided to investigate further.

The first step was finding a way to profile the driver code in a repeatable manner, so I attempted to write a module for the Phoronix Test Suite (pts) that would automatically run the oprofile tool on any of the benchmarks. Unfortunately there turned out to be a couple of issues in making this work reliably, the biggest problem is that when pts issues the command to run the benchmark it doesn't actually issue the final command it usually just calls a shell script in the games install directory that does a few things then goes on to run the benchmark, this makes getting the process id that oprofile needs difficult and error prone, also running tools like callgrind becomes hard. To make this tool work these shell scripts really need to be replaced and the final call to launch the benchmark come from pts itself. I imagine this would be a whole lot of work and testing as every benchmark would need to be reworked which I didn't really have time for so I moved on.

In the end I just took the final command and used that directly with callgrind (its slower than oprofile but it makes measuring small improvements more accurate).

The first thing I noticed when profiling the OpenArena benchmark was how high the cpu usage was for OpenAL, around 14% of all cpu being used during the benchmark was spent processing sound for the game. That seemed way to high so rather than looking at the Mesa drivers I ended up jumping into OpenAL instead. It turned out that depending on your sound card the sound can end up needing to be re-sampled which can be very cpu intensive. And after a bit of a learning curve I ended up submitting a patch that implemented SSE optimisations to significantly reduce CPU use from 14% -> 7%. This change is part of the recently released OpenAL 1.6.

This is pretty much where I left things back in June, as I don't have a high end Radeon card myself I was unable to confirm if this change made an difference to frame rates and ended up moving on to other Mesa work.

Last week however I decided to take another look at my profiling results and as a result ended up submitting a patch to Mesa which reduces cpu use during the OpenArena benchmark by just over 2.5%. Again I have no idea if this actually helps boost frame rates on high end cards but reducing cpu is always good

Using Phoronix Test Suite to Profile CPU Use

First things first you should be profiling the version of Mesa from git. If you don't already have it setup you can see my previous guide for doing so here.

To get Phoronix Test Suite you can clone from git with the following command:

git clone https://github.com/phoronix-test-suite/phoronix-test-suite.git

Then simply go to the new directory and run the main script to start using it:

./phoronix-test-suite

Once you have installed the benchmarks you want to play with you can the run one of them and you will see the command that actually runs the benchmark in the console. On my machine for OpenArena this is:

./openarena.x86_64 +exec pts-openarena-088 +set r_mode -1 +set r_fullscreen 1 +set com_speeds 1 +set r_customWidth 800 +set r_customHeight 600

Now to profile this with callgrind all you need to do is install valgrind (if you don't already have it) and go to the benchmarks install directory:

cd ~/.phoronix-test-suite/installed-tests/pts/openarena-1.5.2/openarena-0.8.8

And you can then run the benchmark in callgrind using a command like this:

valgrind --tool=callgrind ./openarena.x86_64 +exec pts-openarena-088

+set r_mode -1 +set r_fullscreen 1 +set com_speeds 1 +set r_customWidth

800 +set r_customHeight 600

Note: callgrind takes a while to setup its environment and is pretty slow when running, so if you are just seeing a black screen don't reset you computer be patient it will get there

Understanding Profiler Output

Once callgrind has finished running you will have a new file in the games directory named something like: callgrind.out.26859

In case you were wondering the number is just the process id of the application you just profiled.

Now the rest couldn't be easier. All you need to do is install a great tool called KCacheGrind, now you can open this file and will have an excellent overview of where cpu time was spent throughout the benchmark. It will even display the cpu use percentages next to lines of code, as well as many other great features such as sorting by time spent in functions, just take a look around yourself.

Screenshot of KCacheGrind

Optimisation Solutions

Once you have spotted something that's hogging the cpu you can start looking at what can be done to reduce that use. I'm not going to go into detail of all the possible optimisation techniques available as there is plenty of information about that out there, google is your friend. The thing I have been looking at the most is making use of the SSE/AVX functionality available in modern processors, Mesa currently doesn't do a whole lot of these optimisations so there is probably a whole bunch of low hanging fruit out there.

One place that sticks out as a possible place for optimisation is the various hash functions scattered throughout Mesa. For example the hash_key function in the intel i965 driver is one of the largest uses of cpu remaining during the OpenArena benchmark around 0.7% and has a comment above it saying “I'm sure this can be improved on”. There is also a comment like this in the gallium cso_cache.c hash_key function. And the _mesa_hash_data function is another 0.3% of cpu, it uses the FNV-1 hash which I have seen SSE versions of floating around. Another option might be making use of the CRC32 SSE instruction to do some hashing although I haven't looked into it enough to know if it would be suitable or even faster for that matter.

Anyway my point is there is a lot of places someone could look at improving cpu use without much previous knowledge of the Mesa codebase.

If you do decide to have a go at improving something I would be interested to hear about it so feel free to leave a comment below. Also if your not a programmer but decide to do some profiling and see something that looks unusually high then feel free to leave the details below also.

One final link that might be helpful is my guide on How To Start Contributing To Mesa.

Update: Here is a really useful link I forgot to include that lists the intrinsic instructions and allows you to easily group and search them. https://software.intel.com/sites/landingpage/IntrinsicsGuide/

Testing my patches

If anyone out there has a cpu with SSE4.1 and a high end Radeon card I would be interested to know if my patch does actually have any effect of the frame rate in OpenArena. Just leave a comment below.

The post How You Can Help Reduce CPU Usage in Mesa first appeared on ITSqueeze.com.

1. Automated OProfile profiling of Mesa via Phoronix Test Suite

To be honest I haven't used OProfile [1] yet, so I'm not 100% sure yet if this idea makes sense. Currently part of the reason the Open Source drivers have lower performance levels to their closed source counterparts is due to increased CPU overhead. It would be great if profiling was built into the Phoronix Test Suite [2] that way you could analyse the outputs of both tools to do things like look at what was executing when the frame-rates dropped and what percentage of time was spent in those code paths at that point in time. I assume you could do this by using three benchmark runs to see when frames normally drop or cpu usage spikes and enabling/disabling Oprofile a little before/after that time into a 4th run. Maybe you would need to do an additional run for each spot to be analysed so that turning on Oprofile doesn't throw the timing out. This type of feature could also be useful for spotting CPU related performance regressions.

[1] http://oprofile.sourceforge.net
[2] http://www.phoronix-test-suite.com/

2. Do analysis of OpenGL driver quality using Piglit

Piglit is a collection of automated tests for OpenGL and OpenCL implementations. The goal of Piglit is to help improve the quality of open source OpenGL and OpenCL drivers by providing developers with a simple means to perform regression tests.

There has been a lot of attention on the quality of and differences between OpenGL drivers lately. Especially after Valve's Rich Geldreich posted an critical opinion piece on the state of the current drivers [1]. It would be interesting to use piglit to create a picture of driver quality and differences. The idea would be to produce a result similar to the graph and pdf produced with the g-truc samples [2]. I have posted a question to the piglit mailing list to gather ideas on how you would go about this [3].

[1] http://richg42.blogspot.com.au/2014/05/the-truth-on-opengl-driver-quality.html
[2] http://www.g-truc.net/post-0655.html#menu
[3] http://lists.freedesktop.org/archives/piglit/2014-May/010765.html

3. Create a distributed compute network to find possible VRAM optimisations.

Lauri Kasanen created an artificial intelligence project [1] to attempt to find a better strategy for handling VRAM. Two of the conclusions Lauri came to in his thesis [2] are as follows:

“First, the parameters can be adequate, and merely more computing time is needed to find a better solution.”

“Second, it is possible the input parameters are adequate, but the processing power of the network is not. If so, it would need more hidden nodes, which would also mean slower training. This is hinted towards by the inability of the current network to do well at both 64 and 128 MB VRAM and the higher amounts.”

For someone interested in artificial intelligence it might be an interesting project to look at Lauri's work, expanding upon it and porting (all available on github [5]) to a distributed computing network platform such as Boinc [3] where the open source community could then use its collective computing power to attempt to find a better solution.

The Boinc website has some information on porting software and creating a Boinc server [4].

[1] http://www.phoronix.com/scan.php?page=news_item&px=MTY2NDU
[2] http://student.labranet.jamk.fi/~f6133/thesis/thesis.pdf
[3] http://boinc.berkeley.edu
[4] http://boinc.berkeley.edu/trac/wiki/ProjectMain
[5a] Thesis Repo: https://github.com/clbr/jamkthesis
[5b] Code and Data: https://github.com/clbr/hotbos

The post Three interesting (possibly useful) Mesa related project ideas first appeared on ITSqueeze.com.

I thought since its been a while I would provide an update on my ARB_arrays_of_arrays work and while I'm at it would give a bit of an overview of the Mesa GLSL compiler with some other interesting bits and pieces thrown in.

Since my last update the first part of my ARB_arrays_of_arrays support has been reviewed and committed to Mesa. I've also submitted v3 of the piglit tests for review. Work on piglit execution tests and linking support in Mesa is ongoing and I've found myself being slowed down a bit by the need to do some more reading/research on compilers in order to get fully across what is required to finish things off. In order to let you understand what it is I've been doing I thought I'd provide a basic introduction to Mesa's GLSL compiler while also giving some tips for those interested in being able to start their own further research on the topic.

For those that are not aware OpenGL has its own programming language called GLSL used to give developers more direct control of the graphics pipeline. This means that Mesa needs to implement a compiler in order to support GLSL, the code for this compiler is contained in the src/glsl directory of the Mesa source code.

For those interested in understanding more about compilers I stumbled across a free online course put together by Alex Aiken of Stanford University, the lectures can be viewed without signing up here. I've only watched a couple of the lecture so far but they are quite good and cover lots of the basics. The course seems to put a lot of focus on Lexical Analysis (scanner) and Syntax Analysis (parser) but not so much on Intermediate Representation of code which is a little disappointing but understandable given the target audience.

So how does Mesa's GLSL compiler work? Well a crude high level follow diagram would look sometime like this.

Mesa uses Lex and Yacc (actually Flex and Bison in GNU/Linux) to automatically generate a scanner and parser from the files glsl_lexer.ll and glsl_parser.yy respectively (to be exact there is also some extra manually created parser code in glsl_parser_extras.cpp).

From here the parser outputs an abstract syntax tree (AST) which is then converted into and intermediate representation which can be understood by the Intel drivers backend and Gallium. The main code for this step can be found in the file ast_to_hir.cpp but there are also other ast_* files involved in this step.

Note: Before the IR is read in by the backend there are various optimisations and lowering passes performed on the IR.

Currently the IR is also in a tree based form and the code is implemented using a visitor pattern (if your a programmer and never heard of patterns you might want to take a look at the classic book Design Patterns: Elements of Reusable Object-Oriented Software a.k.a Gang of Four book. Knowing about design patterns will not only help you in your daily job but it can be handy to refresh up on them before a job interview)

Anyway recently at FOSDEM 2014 Ian Romanick gave an interesting presentation about the history of Mesa's GLSL compiler design and implementation and highlighted current issues with the treelike structure of the IR, you can view the presentation here.

Ian also references in that presentation two books used by the Intel developers when implementing the current compiler:

Advanced Compiler Design and Implementation

A Retargetable C Compiler: Design and Implementation

So currently this is the point I'm at, the code that been committed implements the yacc changes needed for ARB_arrays_of_arrays and adds support to the AST for arrays of arrays. IR is created from the AST without any changes needed and from my testing appears to execute correctly when the array of arrays is only visible to a single shader, however when the array of arrays are past between shaders or are a uniform then changes are required to the IR linking code and likely the driver backend. I'm currently finding myself needing to look into compiler topics such as register allocation to fully understand this problem.

Currently I have a part working patch for linking inputs and outputs but it seems to be causing gnome shell to crash while I'm testing so obviously still needs some work to avoid regressions.

To summarise I will continue working on the remaining arrays of arrays support I've just been going slow due to needing to do a bit of self education in order to feel confident that I'm going about things correctly. I hope someone has found this post useful/entertaining/educational please feel free to leave any comments/questions below.

Just before I go for a more complete/accurate/lower level description on the GLSL compiler see the readme text in the Mesa src/glsl source directory.

The post Introduction to Mesa's GLSL compiler and ARB_arrays_of_arrays status update first appeared on ITSqueeze.com.

As for the piglit tests I have submitted a large number of compile tests for review, I've got a few execution tests in progress and I have a few geometry shader tests still to write.
All in all I'm very happy with the progress I've made over the past two weeks and I'd like to thank you all again for the opportunity to work on Mesa as an independent developer.

[1] http://lists.freedesktop.org/archives/mesa-dev/2014-January/051641.html

The post Day 10 - Mesa development ARB_arrays_of_arrays first appeared on ITSqueeze.com.

The new branch can be found here: https://github.com/tarceri/Mesa_arrays_of_arrays/compare/wip8

There are still some issues, 3 compile test that were passing are now failing again (but that should be easy to fix up) but overall I'm very pleased with the progress I've made today and look forward to seeing what I can get done tomorrow on the final day which also happens to be my 30th birthday.

The post Day 9 - Mesa development ARB_arrays_of_arrays first appeared on ITSqueeze.com.

I have also done a bit of work rebasing the patches to tidy things up. The latest Mesa branch can be found here: https://github.com/tarceri/Mesa_arrays_of_arrays/compare/rebase6

As far as piglit tests go I finally got started on some execution test today (not yet pushed to github) and I also submitted a version 2 of my compile test patches which includes all the new tests I've been working on [2].

With just two days left I think I will try to focus my remaining time on getting a whole bunch of piglit execution tests written, after all that what this campaign was mostly about. Once I have these done it will allow me to finish the ARB_arrays_of_arrays extension work in my own time.

[1] http://lists.freedesktop.org/archives/mesa-dev/2014-January/051524.html
[2] http://lists.freedesktop.org/archives/piglit/2014-January/008990.html

The post Day 8 - Mesa development ARB_arrays_of_arrays first appeared on ITSqueeze.com.

void main()
{
vec4[2] a[4] = {
{
vec4(1.0), // a[0][0]
vec4(1.0) // a[0][1]
},
{
vec4(1.0), // a[1][0]
vec4(1.0) // a[1][1]
},
{
vec4(1.0), // a[2][0]
vec4(1.0) // a[2][1]
},
{
vec4(1.0), // a[3][0]
vec4(1.0) // a[3][1]
}
}, b[3] = {
{
vec4(1.0), // b[0][0]
vec4(1.0) // b[0][1]
},
{
vec4(1.0), // b[1][0]
vec4(1.0) // b[1][1]
},
{
vec4(1.0), // b[2][0]
vec4(1.0) // b[2][1]
}
}; // b

gl_Position = b[2][1];
}

In total 94/100 tests are passing up from 88/94 yesterday, I only really have 3 to fix now all of which will be fixed at the same time once I get one last piece of the initialisation code done, the other 3 tests actually do pass when I run them on their own just not when I run them together with all the other test so I think something else is causing them to fail I'm not to worried about them for now. Tomorrow I WILL be starting on the execution tests I just couldn't let myself move on until I was fully happy with the compile tests.

The post Day 7 - Mesa development ARB_arrays_of_arrays first appeared on ITSqueeze.com.

A little while back I subscribed to the Libre Office developer mailing list when I was considering working on an important enhancement ($110 reward on offer if anyone's looking for a coding project , I've also written about my findings on where to start here) anyway back to my point. I get the mail in digest form so I usually just opened them have a second or two scan of the subject lines to see if there is anything I'm interested in the delete them. But this morning something caught my eye basically a developer is implementing OpenGL acceleration into Libre Office but is running into some issues because old but still in supported versions of Linux e.g RedHat 5 only support OpenGL 1.x “Sadly Mesa is quite far behind the OpenGL specification (Mesa 10 just supports 3.3 and our RHEL 5 baseline is still in OpenGL 1.x)”

I find this really interesting because when I do my campaigns many people comment saying “do any applications actually use the 4.x extensions yet?”. But as you can see its important for Mesa to be up to date not just for the here and now applications but also so that LTS/Enterprise editions of Linux don't hold back applications developers in future.

Anyway back to my project. First of all sorry for no update yesterday I just didn't get around to it so it will be double posts today one now (in the morning) and one later on today. After day 6 there is 88/94 compile tests passing compared to 82/89 on day 5 and I'm pretty happy now with the coverage of the compile tests so I don't think I will need to write many more.

I hope to at least get to 91/94 passing today at which stage I will feel happy moving onto the execution tests.

Also I'd like to say a quick thanks to Benjamin for running the latest batch of test on the Nvidia binary drivers.

The post Day 6 - Mesa development ARB_arrays_of_arrays first appeared on ITSqueeze.com.