CV for Lee Griffiths, Software Engineer

todo trotter? todo update linked in todo search for poddster online an expand all button? todo check dates #todo fix strong spam todo verify kloc for driver pdf/doc version available here:

Available for work in Hertfordshire, Cambridgeshire or surrounding areas.

The canonical address for this CV is http://www.lee-griffiths.net/cv/. If you're not viewing it there, your version might not be up-to-date.

Available in PDF: 3 pages, 4 pages

.

Contact

[collapse] ▲

Overview

[collapse] ▲

Software developer with 7 years' experience writing WDDM and DirectX 2D/3D graphics drivers in the semiconductor industry for Imagination Technologies. Left in Aug 2015 for a career break, now looking to get back into work.

Worked on large-scale GPU projects, involving many HW and SW teams, with fixed and expensive silicon fabrication deadlines. Experienced full development life-cycle whilst writing embedded, low-level, real-time code for drivers and firmware, and when writing tools for use by developers. Completely comfortable writing non-driver code: desktop apps, 3D apps/games, and utility scripts. Developed programs targeting various OS (Windows, Linux, custom RTOS) on different form-factors (simulated GPUs, tablets, phones, desktop).

Can design, code, test and document software to a high standard. Take pride in personal and professional responsibility. Have a personal emphasis on promoting clear communication between engineers and teams to help avoid ambiguity and reduce tribalism. And also on the testing and documentation of code to help ensure its correctness. Capable of working on solo projects, in teams, or as part of a 300-person effort with little supervision. apable of independent action to get information and work from other teams. Not scared to work on projects that many people rely on. Gained some experience in leading and supervising junior developers in their work.

Key skills

C, Python, (Windows) graphics drivers, debugging IEEE 754 floating point problems present in C and GPU shader code

Professional Experience

[collapse] ▲
Imagination Technologies
August 2008 - August 2015

Imagination Technologies

Leading Software Design Engineer
[collapse] ▲
Graduate S.D.E. (Aug 2008 – Aug 2010)
S.D.E. (Aug 2010 - Jan 2015)
Leading S.D.E. (Jan 2015 - Aug 2015)

Imagination Technologies. Market leading IP company. Owner of brands: PowerVR, MIPS, PURE, Ensigma. PowerVR GPU technology used by many leading-brand smart devices (e.g. all Apple iPads & iPhones, Kindle Fire, Samsung Galaxy), PS Vita, TVs, Laptops, etc.

DirectX driver shipped on Windows-based laptops and tables, and used in the validation and verification of all shipping GPUs.

Role Overview

[collapse] ▲
  • 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... ▼

WDDM/DirectX Team Engineer responsibilities

[collapse] ▲
  • 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... ▼

Tool-smithing in DirectX and PowerVR

[collapse] ▲
  • 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... ▼

Soft Skills, Leadership, and Working Practices

[collapse] ▲
  • 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... ▼

Working with Hardware

[collapse] ▲
  • 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... ▼
APT group, University of Manchester
June 2007 – September 2007

APT group, University of Manchester

Summer Vacation Student
[collapse] ▲

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.

PEVE group, University of Manchester
June 2006 – September 2006

PEVE group, University of Manchester

Summer Vacation Student
[collapse] ▲

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.

School of Computer Science, University of Manchester
August 2005 - July 2008

University of Manchester

Student
[collapse] ▲

Role Overview

In addition to the usual CS topics (algorithms & data structures, databases, AI, etc) there was a particular focus on: Micro-controllers, Digital design of hardware (circuits, CPUs and systems on chip); Operating system design; Programming language theory & compilers;

Example of Academic Projects
  • In Java:
    • Simple multi-threaded servers: e.g. telnet, ftp, a "hotel booking" system.
    • Client software to book slots from a server running a booking database.
    • FAT12, process scheduler, virtual memory implementations.
    • MPEG audio encoding software intended for mobile devices.
  • Developed a compiler & interpreter for an artificial, C-like language (lex, yacc + C)
  • All of the ARM, PIC and C code from the Third Year Project
  • Developed an I2C (I2C) peripheral for an AT91 (ARM7TDMI) in Verilog. Synthesized onto Xilinx Virtex FPGA.
  • Developed "Stump": An ARM-like 16-bit RISC processor in VHDL. (Only simulated, too big for FPGAs available in CS department at the time).
  • Full custom CMOS layout for a ripple carry adder (Cadence suite)
Example Course Topics
CompilersConcurrencyDistributed Computing
Advanced Computer GraphicsOperating SystemsAlgorithms and Data Structures
Digital Design TechniquesDigital Media ProcessingSoftware Engineering
Micro-controllersFrom Transistors to Systems-on-ChipHigh Performance Microprocessor Design
Understanding Programming LanguagesImperative Programming with C and C++Object Oriented Programming in Java
Optical ComputingAI and GamesEnterprise Management for Computer Scientists

Final Year Project

Hand-picked by University staff. Created a hardware platform/system to be used by the CS department for a new 2nd year course-module. Worked with one other student (only joint project of that year!). Given a very basic specification with large freedom of design. Single requirement was that it had to use two specific boards: One ARM and one PIC based. Asked to design a complete, working system as well as sketch feasible applications that could be run on it in the future, with the course potentially changing the app used each year. Delivered a technical report (~20k words) on the project as final year dissertation. Also produced an additional handover report documenting the structure and function of the code/system for the course organisers.

The course apparently used the platform and codebase, with modifications, for a few years with no problems.

Hardware Platform Final Design

Hardware platform with a camera module that could be rotated around two axes. PIC board controlled rotation via stepper and brushed-DC motors. The ARM board worked in tandem with a VDEC1 video decoding co-processor to manipulate camera images, and used an FPGA to help accelerate certain image decoding operations. ARM/PIC/VDEC1 all talked over I2C. Working example provided to staff was simple colour space conversion. A theoretical example application for the platform was motion detection & automated tracking.

Technical Skills used in the project
  • Developed a basic RTOS on the PIC for a student’s "client" application to use.
  • Developed various drivers for both PIC and ARM: Motor control (stepper, brushed DC), communication (I2C, RS232 and custom protocol), Character LED, FPGA interface/downloading, basic user-space stack-tracer for debugging.
  • Programmed: PIC18, AT91SAM9 (ARM9), video decoder (VDEC1/ADV7183B), flash EEPROM, Xilinx Spartan 3.
  • Developed the custom build process and tool chain for the project & course-module. Mix of Bash scripting, C programs (Linux) and some ARM assembly.
  • Experience with Microchip's MPLAB software for programming & debugging the PIC.
  • The project's software is written in C (PIC), PIC assembly, ARM assembly, and tools developed for Linux in C. The image processing/colour-space conversion running on a Xilinx Spartan FPGA was written in VHDL.

Personal Projects

[collapse] ▲
Super-Sleuth
https://bitbucket.org/Poddster/super-sleuth

Super-Sleuth

Prototype for a procedurally-generated detective game featuring the "realistic" simulation of people, their emotions and crimes. The prototype currently uses a text-based input system written in Python. (~4k kloc)

Documentation and design for full game underway.

Programmable Flight Computer for Kerbal Space Program
https://bitbucket.org/Poddster/ksp_pfc

Programmable Flight Computer for Kerbal Space Program

An unfinished mod for Kerbal Space Program (KSP). Attempt at "full system" computer emulation inside of KSP, which would allow players to make automated and self-programmable rocket flights (rather than manual ones, or a completely automated/cheat flights like MehcJeb) and add an element of program- and circuit-design mistake-based-fun to go along with the Rocket-science mistake-based-fun already present in the game.

CPU emulation mostly complete, aside from: adding more op codes, more trap conditions, different configurations (e.g. instantiable as 8/16/24/32-bit CPU etc), and a vigorous re-factoring of the C#.

LLVM backend was planned but not functionally implemented.

Circuit simulation is in research + design stage only. Lots of circuit simulation techniques read about, but no code committed as of yet.

~12kloc lines of C#, ~4.5kloc of test programs written in ksp_pfc assembly.

Python game ranker
https://bitbucket.org/Poddster/python_game_sheet_stuff/src

Python game ranker

A few Python scripts to help clean up an exported Google Sheets spreadsheet and "rank" every computer game I've ever played.

Various small games

Various small games

A multitude of small arcade-era style games in Python/PyGame (pacman, tetris etc).

Pong in C/SDL using MinGW.

A few other larger-scope but completely unfinished games written in XNA/C#

Open Source
Contributed a few very minor tweaks to some Open Source projects, e.g. a fix to CorsixTX's build system.

Academic Qualifications

[collapse] ▲
University of Manchester, School of Computer Science
2005 - 2008
B.Sc. Computer Engineering (Honours), Class 2:1
Third year project
Cardinal Newman College, Preston
2002 - 2005
A-Levels in Computing(A), Maths(B), Environmental Science(B), General Studies (C), Accounting(D)
St. Bede's High School, Lytham
1997 - 2002
11 GCSE grade A-C

Technical skills

[collapse] ▲

Programming languages, technical skills, and technology use

Advanced Use C (c89, c99), DirectX 9/10/11, HLSL (shaders)
Everyday Use Python, Debugging of IEEE 754/floating point problems (C & GPU HW), Windows Xp/Vista/7/8/10 drivers (WDDM, DirectX), WHQL/WHCK/WLK, GPU synchronisation, concurrent programming/data access, cache coherency, GPU assembly,
Frequent Use Assembly (x86, x86-64, ARM, GPU), Direct2D, doxygen, nmake (Microsoft version), msbuild, CMake, MinGW, MSys, SDL (via both PyGame and C API), C#, C++ (C++98, C++03)
Infrequent Java, c11, OpenGL 4.5, GLSL 4.5, gdb, POSIX + Gnu/Linux utilities (grep, sed, awk, etc), Win32 API, COM, XNA 4.0 (+ MonoGame), HTML 5.0, CSS, Event Tracing for Windows (ETW), MISRA C rules
I used this once to do something useful and still vaguely remember how to use it Android, DirectX12, Vulkan, OpenCL, Pic18 assembly, Perl, MATLAB, MPLab, Apple's Metal API, AMD's Mantle API, SystemC, Ruby, Verilog, VHDL, Modern C++ (C++11 C++14), PHP, Oracle SQL & MySQL, LLVM backend + LLVM language ref, Lex, Yacc, Bash scripts

Tools use:

Advanced Knowledge git, Pix For Windows
Configure/Use Mantis bug tracker, ReviewBoard, CVS, SVN, Mercurial (Hg)
Normal Everyday Use Windows, Linux, Visual Studio, WinDBG (kernel + user-mode), Perforce, MKS, Microsoft Project (Gannt chart), RenderDoc, Serena business mishaps (formally TeamTrack), CA Clarity PPM, Openproject, Bugzilla, Eclipse, Jenkins, Microsoft connect, Microsoft Driver Verifier
Used a Few Times GPUView, PVRTune, Intel VTune, ApiTrace, OllyDbg, Cadence Tools (Schematic & CMOS Layout editors. NC-Verilog/NCSim & Verilog XL simulators), Mentor Graphics (Schematic), SoftICE, XPerf, LaTeX

Hardware skills

Micro‑controllers All PowerVR GPUs from MBX to Rogue (series 3-7), parts of PowerVR Series 8, some PowerVR video & display cores, Intel Poulsbo (GMA 500), Intel Atoms, AT91SAM9621 (ARM9 based), AT91M40800 (ARM7), PIC18LF452, Xilinx Virtex & Spartan FPGAs, Analog Devices ADV7183B (Digilent VDEC1 video decoder chip). Some time with Arduino and Raspberry Pi.
Peripheral Hardware & Protocols PCI bus, I2C, UART, USART, RS232, SPI. Analogue and digital PIOs. Interrupts, Power Management controllers etc. Motor control, Character LCDs. Watchdog/One-shot timers, 555 timers, etc.
Practical tools Oscilloscopes, Signal Generators, Soldering Iron, Digital multimeters/Volt-Ohm meters

Misc Skills/Qualifications

[collapse] ▲