Introduction to PFX Version 3

The purpose of this document is to act as a specification for the PowerVR Effects (PFX) format version 3 (PFX specification version 3.0.0).

What is PFX?

The PFX format is a small, simple, easy to use effects format consisting of several blocks that describe how a given graphics effect is put together. As of version 3, it is XML-based.

As a minimum, a correctly formatted PFX file consists of:

  • A root <pfx> element containing the rest of the document

  • Zero or more <effect> elements

  • Zero or more <shader> elements

  • Zero or more <buffer> elements

  • Zero or more <texture> elements

  • Zero or more <pipeline> elements

The opening of the pfx tag (the characters ‘<’ ‘p’ ‘f’ ‘x’) must always be the first 4 characters in the document as it is used by the PFX parsers to recognize that it is an XML-based PFX file (as opposed to the square-bracket based PFX files of version 2 and backwards).

The exact use of these items will be described in the relevant sections, but roughly, the main structure is:

  • <effect> elements, will describe <pass> elements (rendering passes that are intended to render to the backbuffer or to specific <texture> elements)

  • Each of those passes will contain <subpass> elements which will contain references to <pipeline> elements with “selectors” (conditions), which will be used to select what <pipeline> element is suitable to render each item.

  • The <pipeline> definition elements will contain the entire definition of a graphics pipeline configuration, with references to <shader>, <texture>, and <buffer> elements and other configuration options.

  • When rendering a model (Renderable) with an implementation, it is added to one or more subpasses (<subpass> elements). The actual pipelines used to render each model are selected by the conditions of them.

  • Then, the various data carried by the renderable (vertex attributes, material properties, textures, and so on) can be matched to the various pipeline data items (vertex attributes, uniforms, entries in buffers, textures) via the mechanism of semantics which are essentially strings describing what each pipeline item actually means, in a language that the implementation should understand.

Element and attribute names are all case-sensitive. Pre-defined attribute values that are mentioned in this document are case-insensitive, and many times have different aliases. For example, when defining a dynamic uniform buffer object, all the following values would be accepted:

  • uniformdynamic


  • UniformDynamic

  • dynamicUniform