• Worked as a senior member of the WDDM team (~30 people), writing WDDM/DirectX 9, 10, 11 drivers for Windows XP/Vista/7/8/10, in both user-land and kernel mode C.
  • Experienced all levels of the software development life-cycle in their GPU drivers, notably the design and implementation of a DirectX 9/10/11 driver that started as an initial 0-file project and ended up being delivered to multiple customers (Intel, Allwinner) with a full WHQL pass on Windows (Vista, 7 and 8.1), complete with following maintenance periods, on Intel x86, x64 and ARM based platforms.
  • Mentored new and junior engineers. Helped train, educate and present DirectX topics to SW/HW engineers. Advised HW teams on DirectX spec requirements and signed-off some hardware specs.
  • Helped indirectly support customers by providing technical answers in tickets (IPGear, TeamTrack). Have been "responsible engineer" for WDDM/DirectX team when Product Managers are taping-out a core and driving all bugs to 0, or for when a customer's testing/validation fails on a DirectX test.
• Responsible for design, architecture and direct implementation of large sections of the DirectX driver codebase:
  • Majority of work done in user-land DirectX driver dealing with the "shader stack", e.g. shader program compilation, execution, related GPU data/code memory management.
  • Other areas of lead responsibility: DirectX 11 tessellation, DirectX/GPU command stream/packet formation, constant buffers, code that read "apphints" from the windows registry and .ini files (in both user and kernel drivers), code that dumped shader log files. Supervised DirectCompute implementation.
  • Had significant input into design and architecture of other areas of the driver. Worked on every file in the WDDM/DirectX driver codebases in a fire-fighting/debugging fashion. (200kloc)
• Worked on many useful software tools that were used in the WDDM team and PowerVR wide. e.g. Python scripts for: C-codegen, translating between source-control systems.
• Regular contributor to the vital tool "objanal": a fast GPU simulator and important driver debug tool used by almost all HW/SW/Sim engineers in PowerVR (~300 people)
  • Performance sensitive code due to important validation/test system turnaround times.
  • Helped code review all patches for objanal, once a code review system was in place.
  • Contributed to design and architecture discussions.
  • Objanal written in C. Produced a .dll (or .so) that was driven by various frontends.
  • Helped make frontends: command line (Python), graphical (C#/DirectX/OpenGL).
• Helped innovate the WDDM/DirectX team by introducing more modern and efficient working practices.
  • Helped introduce a peer code-review system into the WDDM/DirectX team and pushed for the concept to PowerVR management at large.
    • Helped implement mandatory code reviews for all WDDM/DirectX code via ReviewBoard.
    • Acted as 'back stop' to ensure every single commit to the WDDM/DirectX codebase on ReviewBoard was reviewed by someone, usually myself.
  • Helped introduce, implement and maintain a continuous-integration regression test environment for the driver based on thousands of small-scale tests that all ran at the touch of a button, rather than manual testing via a few, very complex games & 3D apps.
    • A dll extension to Python, using the Python/C API. It allowed 3D-apps to be written in Python using the DX10 API, rather than in C or C++.
    • Worked on a set of Python scripts and associated 'shell' environment, using the comtypes and ctypes libraries. They enabled 3D integration test-apps to be written in Python using the DX9 and DX11 APIs, rather than in C or C++.
    • Wrote hundreds of 3D test apps using DirectX 9, 10, 11 to validate the driver and GPU hardware. Majority written in Python (via the dx10 .dll extension and the dx9, dx11 shells), some in C or C++ using COM/DirectX.
    • Helped develop + maintain QA/testing tools: an automated distributed, multi-threaded tool for test scheduling and execution, test-image comparison and error reporting tools, an email delivery report system, and system configuration parsing scripts. Python
    • Maintained a report hosting website that dynamically generated its contents via Django (earlier PHP) and a set of hard-lockup detection tools.
  • Continually pushed for improved working practices at all organisation levels (e.g. code reviews for all, better source control, improved documentation, change project organisation etc).
• Debugged/Reverse-engineered the DirectX API output of many 3D apps, games & game engines in an effort to fix faulty images. Found and debugged many IEE 754 floating point problems in various forms e.g. generated shader code, HW FPU designs, and purely software FPU implementations.
• Found, triaged, debugged, proved and reported many hardware bugs in simulated-, prototyped- and live- hardware designs which would have been very expensive to fix if not found.
  • Designed and implemented efficient driver workarounds for any unfixable or "won't fix" HW problems.
• Worked with various build systems for driver and tools. nmake/msbuild/visual studio.
• Understood the maths involved in creating 3D and 2D graphics and used this to write driver code and 3D apps. Helped educate junior team members in terms of related maths problems. exapct dupe?
  • E.g. vector coordinate spaces, geometry tessellation, vertex and geometry manipulations via linear algebra and matrix transformations, viewport transforms, polygon rasterization, per-sample triangle iteration, LOD/mipmap selection, texture sampling techniques (e.g. texel fetch/point sampling, gather4, bilinear, trilinear, anisotropic filters, PCF style comparison filters), 3D textures, cubemaps, sRGB/gamma colour spaces, colour space conversions, anti-aliasing techniques (MSAA, SSAA, FXAA etc)
• Have extensive and in-depth knowledge of Imagination's GPU hardware and their unique Tile-Based Deferred Rendering design. Have a complete understanding of Microsoft's DirectX 9, DirectX 10, and DirectX 11 specs. Used this knowledge to implement driver and continually help educate and guide other HW/SW engineers with their own design problems.
  • Provided technical input and feedback (from a 'DirectX point of view') into the design of different modules of PowerVR GPUs (including some key marketable features like GPU Tessellation) to ensure they were usable by the driver and would meet Microsoft's specs.
• more... ▼

• Responsible for design, architecture and direct implementation of large sections of the DirectX driver codebase:
  • Majority of work done in user-land DirectX driver dealing with the "shader stack", e.g. shader program compilation, execution, related GPU data/code memory management.
  • Other areas of lead responsibility: DirectX 11 tessellation, GPU command stream/packet formation, constant buffers, code that read "apphints" from the windows registry and .ini files (in both user and kernel drivers), code that dumped shader log files. Supervised DirectCompute implementation. Worked in Window's Kernel-mode and User-mode environments in C.
  • Had significant input into design and architecture of other areas of the driver. Worked on every file in the WDDM/DirectX driver codebases in a fire-fighting/debugging fashion. (200kloc)
  • Able to guide and assist all other developers on the team with their own implementations using this wide driver knowledge.
  • The driver was broadly multi-threaded at API entry points, and designs drawn up for the DirectX 12 driver were highly multi-threaded. Had to take these current and future access patterns into account when designing key driver data structures.
  • more... ▼
• Debugged and fixed drivers on various Windows platforms (Xp to 10) to help make them pass Microsoft WHQL/WHCK/WLK test suites and therefore attain Microsoft 'logo' certification and Microsoft safety signing.
  • WHQL/WHCK: notoriously 'thorough' test system that tested every possible permutation of valid and invalid input to a drivers entry-points, via completely obfuscated and difficult-to-debug test apps. Kernel and usermode debugging via WinDbg, in-house tools, driver verifier, SoftICE, OllyDbg
• Debugged/Reverse-engineered the DirectX API output of many 3D apps, games & game engines in an effort to fix faulty images. Sometimes the driver needed fixing, sometimes the app was using the DirectX API incorrectly which required a game/game-engine specific workaround (aka "apphint") implementing in the driver. Pix For Windows, ApiTrace, RenderDoc, log files, in-house tools
• Debugged numerous problems with IEEE 754 floating-point and fixed-point numbers on various implementations and platforms:
  • e.g. Accuracy/precision problems (ulp), mantissa under/overflow, comparison problems, rounding modes and rounding errors, normalised/denormalised, non-normalised, incorrect flushing behaviour, general issues with float/double usage in C and C++.
  • Wrote and maintained a few tools that can view and manipulate the binary representation of different floats. C, Python, Win32 GUI.
  • Environments: C on x86/x64 and ARM (produced by different compilers e.g. MSVC, gcc), different implementations of GPU hardware, pure software implementations (e.g. used by various GPU simulators).
  • Formats: IEEE 754 (F64, F32, F16). F11 and F10 bit from DirectX texture formats such as r11g11b10_float.
  • more... ▼
• Tweaked the performance of WDDM/DirectX drivers at a C language level. Optimised the GPU instructions the driver generates using various profiler tools. GPUView, PVRTune, Intel VTune, log-based metrics, Event Tracing for Windows (ETW), XPerf
• Had virtually memorised all relevant parts of Microsoft's WDDM and DirectX 6, 7, 8, 9, 10, and 11 specs. Continually used this knowledge to help HW and SW engineers who wanted to know both the "letter and spirit" of the of the spec's law.
  • Provided technical input and feedback (from a 'DirectX point of view') into the design of different HW modules of PowerVR GPUs (including some key marketable features like GPU Tessellation) to ensure they were usable by the driver and would meet Microsoft's specs.
  • Have read and critiqued Microsoft's DirectX 12 spec. Helped draw up designs for the architectural changes necessary to change a DirectX 11 driver into a DirectX 12 one.
  • Had an interest in and read "competing" specs to better understand future driver architectures.
    • e.g. OpenGL, Vulkan, Apple's Metal, AMD's Mantle
  • more... ▼
• Helped "police" the doxygen-style comments in the driver to ensure they're of a reasonable standard and that the final doxygen-derived documentation was useful.
  • Helped maintain the doxygen build target and tool invocation environment.
• Maintained nmake and msbuild build environments. Helped transition driver build system from nmake to msbuild. Made nmake files from scratch for various driver modules/tools. Utilised CMake build system and tampered with the occasional perl file used by the build process.
• Understood the maths involved in creating 3D and 2D graphics and used this to write driver code and 3D apps. Helped educate junior team members in terms of related maths problems.
  • E.g. vector coordinate spaces, geometry tessellation, vertex and geometry manipulations via linear algebra and matrix transformations, viewport transforms, polygon rasterization, per-sample triangle iteration, LOD/mipmap selection, texture sampling techniques (e.g. texel fetch/point sampling, gather4, bilinear, trilinear, anisotropic filters, PCF style comparison filters), 3D textures, cubemaps, sRGB/gamma colour spaces, colour space conversions, anti-aliasing techniques (MSAA, SSAA, FXAA etc), Taylor series expansion
• Worked with data transfer over the PCI bus.
• more... ▼

• Regular contributor to the vital tool "objanal": a fast GPU simulator and important driver debug tool used by almost all HW/SW/Sim engineers in PowerVR (~300 people)
  • Code was performance sensitive as the tool could be critical to turnaround times of important validation/test system.
  • Helped code review all patches for objanal, once a code review system was in place.
  • Contributed to discussions about design and architecture issues and the future of objanal.
  • Tool consumed pdump files and simluated GPU hardware. Its software rasterizer produced images similar to those expected from GPU hardware, simulated all shaders, and most usefully produced a human-readable version of the GPU command stream and shader instructions
    • Multiple versions of objanal existed, for various different PowerVR architectures.
    • Most versions of objanal were written in C and produced a .dll (or .so) that could be driven by various other programs/frontends.
    • more... ▼
  • Helped make frontends: command line (Python), graphical (C#/DirectX/OpenGL).
  • Tool was broadly multi-threaded, which code has to be aware of.
  • Helped people of all skill levels use objanal, fixed any sim bugs found, improved command line UI if needed etc
  • more... ▼
• Helped introduce, implement and maintain a continuous-integration regression test environment that tests a WDDM graphics driver; an email + web based report system, and hundreds of 3D testapps to go along with it. Python
  • Worked on a dll extension to Python, using the Python/C API. It allowed 3D apps to be written in Python using the DX10 API, rather than in C or C++.
  • Worked on a set of Python scripts and associated 'shell' environment, using the comtypes and ctypes libraries. They enabled 3D integration test-apps to be written in Python using the DX9 and DX11 APIs, rather than in C or C++.
    • The scripts and shell environment were performance sensitive, as they affected the turnaround time of the WDDM team's continuous-integration test environment. DirectX apis, Win32 api, COM (via comtypes and ctypes)
    • Scripts contained multi-threading & cross-thread synchronisation to read Windows debug output and print it whilst the 3D app continued to run.
    • more... ▼
  • Wrote hundreds of 3D test apps using DirectX 9, 10, 11 to validate the driver and GPU hardware. Majority in Python, some in C or C++.
    • All of the Python scripts were built off of the DX9 and DX11 Python script environment or the DX10 .dll extension.
    • The C and C++ apps were just normal COM/DirectX.
    • Auto-generated hundreds more Python based 3D test-apps, using other Python scripts.
    • The individual Python scripts could be run easily on various machines and platforms with few environment problems and no compiling process (which cause many side-by-side problems on later versions of windows). Scripts could also be edited in-situ to test new ideas and help with rapid prototyping when tracking down a driver regression.
    • more... ▼
  • Contributed to in-house test execution environment tools i.e. Various automated multi-computer, multi-threaded test scheduling and execution tools.
    • e.g. a continuous-integration driver-build testing tool, a pre-checkin smoke test system, test-image comparison and error reporting tools, and an email delivery report system. Python
    • Maintained a report hosting website that dynamically generated its contents via Django (and earlier PHP) and a set of hard-lockup detection tools.
    • Acted in a fire-fighting capacity to fix (or to get someone else to fix) the driver whenever the system flagged up driver regressions, and liaised with external teams when they were 'at fault'.
    • The system helped the DirectX driver mainline stay in a consistent 'good' state and allowed all developers to know when external teams/dependencies regressed the driver.
    • The system helped generate stats (e.g. total pass-rate) for all of the various driver builds/configs, for all of the various HW configs, across many of the different Windows environments. Allowed comparison between the various sub-projects in the WDDM team.
    • Later the use of virutal machines was integrated into the system.
    • more... ▼
  • Worked on implementing a limited form of a unit-test environment for the C driver, mainly for "critical" sections, driven by special build rules.
  • more... ▼
• todo soft skill? Helped lobby management to unify source control tool across departments and change source control away from the archaic MKS to anything better. Helped evaluate the "best" source control (from a working software engineer's point-of-view) to be used PowerVR-wide.
  • Did so from a choice of Mercurial (hg), Git, Perforce, CVS, SVN.
  • Management eventually settled on Perforce.
  • more... ▼
• Wrote and maintained scripts for the WDDM team that kept live-synchronisation of source code between various source control systems, depending upon what the company was transitioning between or testing at the time.
  • Scripts that synced between MKS<->git, git<->CVS, git<->Perforce, Mercurial (Hg) <-> MKS, Hg <-> Perforce.
  • Scripts all written in Python
• Contributed to discussion, design, and maintenance of standard libraries, headers, and tools used across the PowerVR Software division, e.g.:
  • PowerVR "standard library" (.c and h files) containing common types and functions used by all driver teams (WDDM, OpenGL, OpenCL, Vulkan etc) and on various platforms (Windows/Linux/Android/Windows CE/etc).
    • e.g. String libraries, common array types, common utility methods, common numerical calculations required by the GPUs.
    • Helped upgrade these PowerVR standard libraries from c89 to c99.
      • Including workarounds like home-rolled C99 static asserts for platforms that didn't have them (Windows CE!)
  • Python scripts to generate a C API (.c and .h files), which was used by all PowerVR drivers, that described and translated between GPU and API texture formats/descriptions.
  • "pdump" tools, that PowerVR drivers used to log the system commands and GPU-commands they would emit.
    • These pdump logs could be played back in various simulators and emulators, and were the backbone of the PowerVR HW test and verification system.
    • pdump files, and tools to simulate and read them, were often given to customers for their validation and verification process.
  • more... ▼
• Contributed to code that was under external guidelines and coding styles:
  • e.g. MISRA C, Linux Kernel patches.
• Utilised many of Imagination's cycle accurate GPU simulators written in C++ and SystemC. Occasionally debugged their source code to help get more information about what the theoretical/simulated HW was doing. Very occasionally found and helped fixed bugs in the sim's source code.
• more... ▼

• Helped introduce a peer code-review system into the WDDM/DirectX team and pushed for the concept to PowerVR management at large.
  • Helped implement mandatory code reviews for all WDDM/DirectX code once ReviewBoard was in use.
  • Acted as 'back stop' to ensure every single commit to the WDDM/DirectX codebase on ReviewBoard was reviewed by someone, usually myself.
  • Code-reviews helped:
    • Stop the team from introducing new bugs or architectural "misuse" into the C drivers
    • Consolidate coding styles
    • Give everyone, from junior to senior, UK or Poland based, a broader knowledge of what work is going on in the driver.
      • Also an invaluable learning experience, as it allows any team members to see the types of bugs anyone can make when writing driver code and gives them a method to avoid or fix them.
    • Increase eyes on code-areas that usually only a single person touched, which allowed knowledge redundancy in staffing (e.g. illness) and allowed people to suggest alternative implementations.
  • Initially done via email for important code areas or for large branch merges.
    • Later via ReviewBoard, after the tool was finally "officially" approved PowerVR-wide.
  • more... ▼
• Helped push management to change the way the driver is tested, and helped implement the necessary changes.
  • Change was away from a driver test environment based solely on a small number of manually run 3D-apps, games, and demos scenes that were graphically very complex (and therefore difficult to debug) and instead towards a continuous-integration test environment using thousands of smaller and less complex testapps automatically run at the press of a single button.
    • Python scripts allowed development and maintenance of tests to be faster and easier and allowed spotting driver regressions to be a relatively simple task that was easy to focus in on, rather than the old case of a single pixel in a full-screen app being incorrect.
    • The new test scripts, test harness, test environment and email-report systems were written in Python. Details here.
  • more... ▼
• Provided advice and technical implementations to help resolve tickets/bugs/issues reported by Imagination's customers. Sometimes even on behalf of other driver teams, e.g. if their equivalent team-members were off-sick or travelling for work etc.
• Trusted to be the responsible, on-demand engineer for the WDDM team when Project Management and a customer were driving a design down to 0-bugs.
  • Tasked with triaging outstanding errors in any validation tests that used the DirectX API and then fixing (or delegating a fix to) the driver, or even pushing back if required.
  • All against tight deadlines set by Customers to meet exceedingly expensive silicon fabrication deadlines.
• Mentored new and junior team members in terms of tool use, coding style & ability and the general working practices used by the team and company.
• Requested, and received, a direct line-manager for a sub-team when it became clear that the self-managing working practice of the sub-team was becoming unsustainable under the workload and responsibilities.
• Was responsible for monitoring the DirectX driver builds and ensuring it's fixed in a reasonable timeframe.
  • Originally, on a daily cadence by propriety build system
  • After the introduction of Jenkins and continuous-integration build process, after each commit.
  • Mostly to catch problems caused by external dependencies. ReviewBoard and the continuous-integration regression test system kept driver changes building and passing tests.
  • more... ▼
• Continually proposed improvements to the documentation and communication processes within the WDDM team in an effort to help the engineers in the team work better together.
  • e.g. encouraged information sharing across sub-teams
    • To help avoid people wasting their time by debugging issues know to and being debugged by other engineers.
    • To help coordinate and present a "unified voice" when communicating with external teams.
    Examples of proposed ideas to aid information sharing:
    • Collecting the WDDM team's body of knowledge in a single searchable location
      e.g.
      • "how to" technical documentation for the team. ("how to" use certain tools, "how to" debug complex issues etc)
      • New-starter documentation
    • More open tracking of the tasks done by all people
    • Taking and sharing minutes from team meetings
    • More frequent, quicker and useful roundtable/standup agile-style team meetings to help speed up scheduled meetings without losing any information.
  • Helped assess and select systems for in-team project management, bug tracking and knowledge documentation. Management went with OpenProject
  • Helped promote a positive attitude towards the office based in Poland to avoid any "us vs.them" mentality setting into the UK team and therefore helped avoid tribalism in the code, undermining the work both offices did.
  • more... ▼
• Filed accurate and helpful bug reports/tasks/tickets for various code bases in the company, using different issue tracking systems, intended to be read by people of differing skill-levels, English abilities and HW experience: e.g. SW/HW engineers and managers, Project Managers, Biz Dev. Mantis, Serena business mashups (formally TeamTrack), Openproject, Bugzilla
• Trusted with a Microsoft connect account. Helped organise the downloading of new specs/tools/tests and communicating these updates to the rest of the team (and company) that didn't have a connect account.
• Organised, chaired, and minuted meetings as required
  • E.g. Chaired Whole- or Sub- Team meetings, if manager was absent
  • If email was not sufficient, organised meetings to discussed driver design/implementation, tools meetings. In-team, cross SW division, or across SW/HW group.
  • Organised mentoring/training meetings if required
  • more... ▼
• Organised and planned work.
  • Worked on many different tasks at once and 'billed' them to the correct project accordingly.
  • Planned out long and short term workloads.
  • Helped other team-members estimate time for their tasks, to fulfil for entire-team's plan/Gannt charts.
  • Used: Microsoft Project in a basic fashion to plan time/resources, Serena business mishaps (formally TeamTrack), CA Clarity PPM.
  • more... ▼
• more... ▼

• Wrote driver code to transform DirectX library API/DDI commands into the correct GPU control stream commands in order to control PowerVR GPUs in the most efficient way possible, involving:
  • GPU multi-core synchronisation/scheduling, CPU-GPU synchronisation, GPU-CPU cache coherency, data loading and transfer (DMA and CPU driven), state updates for various modules, heap allocation/memory mapping for all relevant GPU modules, invocation of various different types of embedded micro-controllers on the GPU (e.g. execution of data sequencing controllers or the hugely parallel 'shader' programs).
  • more... ▼
• Designed and debugged programs for various different types of propriety embedded micro-controllers on the PowerVR GPUs, most importantly efficient code for the high performance 'shader' micro-controllers that ran in parallel (e.g. ~1024 instances) at up to 1TFLOPs (depending on GPU), in both their native bytecodes or a propriety PowerVR assembler.
• Continually experienced the debugging of very difficult low-information problems in a highly parallel GPU environment, mostly via reading driver dump logs (or running them through simulation tools). Debugged the driver/HW in a live environment (both emulated HW or real silicon).
• When required, attended weekly division-level HW-SW sync-up meetings to provide technical input from a WDDM SW (sometimes just a SW) perspective.
• Read and understood the documentation for ~60 different GPU variants across 4 different PowerVR architectures, at both a functional or specification level (depending on module). Have a deep knowledge of certain modules, and a detailed overall overview of the GPU HW, which allowed assistance to be provided to other SW developers (in the WDDM team and occasionally across other SW teams) e.g. with debugging their problems, implementing an optimal driver solution for the HW, or general "how it works" training sessions.
• Helped foster a healthy dialog between the various hardware teams and the WDDM/DirectX SW team. Personally maintained a good working relationship, via constant communication, with HW engineers e.g. through meetings, emails and phone-calls etc.:
  1. to help diagnose and triage issues the WDDM SW team were seeing;
  2. to collaborate and advise HW engineers on DirectX spec requirements and the HW implementation for them, and be on the lookout for any "gotchas" in their design choices;
  3. to provide advice on how easy to use and efficiently program a particular HW design was with regards to the DirectX spec;
  4. to get feedback from them about the intended optimal solution/programming of the HW designs and ensured the WDDM SW team did it this way;
• Occasionally read VHDL and Verilog code to figure out how a HW module is intended to work. Sometimes out of necessity (e.g. either due to missing/incomplete/incorrect documentation) or to help track down a bug where the perceived behaviour doesn't match the expected behaviour.
• Have built VHDL from source to generate a netlist that is run on a Cadence provided emulator, and run Windows WDDM drivers live against that emulator environment.
• more... ▼

Role Overview

Started work on the course materials that the APT group would use for a new second-year course module that was due to be taught the following year. Work continued on into my third year project. For more details see UoM final year project.

Role Overview

Created a new website for the PEVE group that would live on CS Department's webpages (cs.man.ac.uk). It had to match the "new" style template used by the rest of the CS department.

Role Overview