devkitpro / picasso

Homebrew PICA200 shader assembler

picasso

Introduction

picasso is a PICA200 shader assembler, written in C++. The PICA200 is the GPU used by the Nintendo 3DS.

picasso comes with a manual Manual.md that explains the shader language. example.vsh is simple example that demonstrates it.

Building

A working C++ compiler for the host is required (Windows users: use TDM-GCC), plus autotools. Use the following commands to build the program:

./autogen.sh
./configure
make

Shout-outs

• smea for reverse-engineering the PICA200, writing documentation, working hard & making aemstro_as.py (the original homebrew PICA200 shader assembler)
• neobrain for making nihstro-assemble, whose syntax inspired that of picasso and whose usage of boost inspired me to make my own assembler without hefty dependencies.

picasso's Issues

mova does not set a destination mask

The MOVA instruction supports a destination mask, with x and y controlling writes to a0 and a1 from components x and y of the source. Picasso doesn't let you control this, and furthermore sets the swizzle to have both components disabled, meaning that MOVA instructions it emits are always no-ops.

No obvious way to find version number

The picasso included in my devkitarm installation (using the linux perl updated) doesn't even seem to understand "mova a0, c10.x" but I have no way to figure out what version of picasso it is.

picasso should include the version number in the help text or print it when something such as "-v" is specified on cli.

Picasso mis-compiles multiple .constf directives in a single shader

Swizzling do not work in output registers - and only manual knows about it

From manual:

Output parameters have an output mask instead of a swizzling mask. This allows the shader to write to some components of a register without affecting the others. In picasso, the output mask is parsed exactly the same way as the swizzling mask, enabling write access for the components that are used in it. By default it is also xyzw; that is, writing to all components.

Normally, what is not forbidden is allowed. Therefore I wrote:
mov r0.yx, r1.xy
But this doesn't work as expected and you can only find out by reading documentation. It will work like this as I understand:
mov r0.xy, r1.xy
Which is not programmer's intention.

I think changing the order of values in output register is a clear mistake and should be reported by picasso as an error (or at least warning).

no-op not inserted after label at end of loop

As an example,

.consti loopParams(3, 0, 1, 0)
.setb b0 true

.proc main
    for loopParams
        jmpu b0, label
        label:
    .end
.end

does not have a no-op inserted after label to prevent unintended early exits.

Segfault with (invalid) shaders

.in input r14

.proc main
.end

Errors would be prettier.

Feature request: Support inverting condition for JMPU

JMPU supports inverting the condition (jumping when the uniform is false instead of true) if you set bit 0 to 1. Suggested syntax: jmpu !my_condition, target_label.

Segfault when input file can't be opened

picasso segfaults (at least on windows) when the input file doesn't exist.

Throw an error when putting the relative address constant offset on the wrong side

When using relative addressing, writing [1+a.x] results in the 1+ being silently ignored - this should probably be a syntax error instead, or do the same as [a.x+1].

no output file specified

happens every time i use picasso -h vshader_shbin.h vshader.v.pica

Is there a problem using 2 input registers as sources for some operations?

Two methods that should result the same, yet they don't. The former seems to not work, yet the latter does.

add r0, v3, -v1 <----
mov r1, v1
add r2, v1, r0

---

mov r3, v1
mov r4, v3

add r0, r4, -r3 <-----
mov r1, v1
add r2, v1, r0

I know these methods clearly aren't special, and that simple MOVs for each would make the result in less instructions, but this was for initial testing purposes of range of 0.0 to 1.0, as I attempted to use MAD with a fraction to get a value between two input registers (the fraction also part of an input register), yet my results from using 2 input registers as sources (rather than at least 1 temporary) in an ADD operation were not creating results that should have been.

Just wondering if this is a limitation to the 3DS shader code, or if this is a bug in this shader compiler.