The environment for building the DLL needs to be quite different from
the environment for building the programs, in order to get
the dllexport/dllimport attribute done currectly. I don't know how MinGW
managed to build the programs, but MS linker refuses to link symbols with
mismatching attributes.
This is a substantial reorganization, This particular commit enables:
- building the progs for unices platforms
- glew is now built as a shared library (it is the default, and it is
inconvenient and pointless to shift away from that default)
- all progs get built by default
Some of the demo progams legitimately need the functionality
that's disabled by WIN32_LEAN_AND_MEAN.
Instead the solution should be to define WIN32_LEAN_AND_MEAN just before
including windows.h on a case by case basis.
GLAPI on windows is more than "extern" -- it includes the --, so the
mismatch between condrender.[ch] prototypes causes "different linkage"
errors on windows.
If we create multiple instances of an nv50_reg referencing
them same resource, register allocation from alloc_reg has
to be done with the original nv50_reg.
This negation would only be triggered in situations
where it's incorrect.
The caller of set_immd should negate the immediate value
in the instruction itself if desired, and will also know
if it's a float or an int.
ADD TEMP[0], CONST[0], -IMMD[0] would load the immediate
into extra TEMP, negated, and set the negate flag in add
as well - double negation.
These functions clear color/depth/stencil buffers with a value that's
passed to the function, rather than the context clear values.
For now these functions are implemented in terms of the existing
ctx->Driver.Clear() hook. In the future when we have non-normalized
integer and unsigned integer color buffer formats we'll need new
driver hook(s) to pass int and uint clear values to the driver.
Note: these functions are not hooked into the dispatch table at this time.
Currently in nvXX_transfer_new a temporary as large as the surface is created.
If the subrectangle is not the whole texture we would need to read
back the whole texture, but we aren't.
Thus, everything but the subrectangle specified is loaded as garbage.
This can be seen in progs/demos/ray.
This patch fixes the problem by creating a temporary that covers only
the desired subrectangle.
That makes us hit an alignment assert in nv04_surface_2d.c. Fix it
using the point registers instead of manipulating the swizzled surface
offset to account for the destination coordinates (which do not seem
to have a 1024 limit).
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
José Fonseca