Must not change to/from swrast after Render.Start or bad things will happen.
(Driver will still somewhat incorrectly report an implementation error,
and apps can't really figure out if a prog is natively supported as validation
is later - could try doing it earlier to give some hint at least, even though
native status may still change later due to fog etc.)
The clamping for these values depends on whether we're drawing AA or non-AA
points, lines. Defer clamping until drawing time. Drivers could compute and
keep clamped AA and clamped non-AA values if desired.
Make sure the relevant fields in window fbs get updated at appropriate time
(those are NOT the same as fbos!!!), and fix up related code accordingly.
This is a bit ugly, but there's a reason the issues section in EXT_fbo is
a couple hundred pages long...
Hopefully correct now.
Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
Construct the vertprog instruction in the 4 DWORD parts...
DWORD 0: Opcode and Output.
DWORD 1: First Argument.
DWORD 2: Second Argument.
DWORD 3: Third Argument.
Allow the opcode translation functions to generate more than one instruction;
useful for when an instruction must be emulated. FLR, XPD, etc.
the framebuffer objects attached to drawables can have invalidate state
associated with them, since for the window framebuffer this is per-context
state and not per-fbo state. Since drivers rely on that information
(otherwise would need to check if currently the window-framebuffer is
bound in a lot of places) fix it up in _mesa_make_current (ugly).
(Brought over from i915tex_privbuffers, where it fixes xdemos/wincopy
when switching to front buffer rendering.)
