| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
And don't use the display-target path to allocate them.
|
|
|
|
|
|
For many envirionments it's necessary to allocate display targets
in a window-system friendly manner. Add facilities so that a driver
can tell if a texture is likely to be used to generate a display surface
and if use special allocation paths if necessary.
Hook up softpipe to call into the winsys->surface_alloc_storage()
routine in this case, though we probably want to change that interface
slightly also.
|
|
Allocate a texture containing storage instead.
Also clean up ACCUM buffer allocation slightly -- drivers will need
some changes to texture allocation logic to accomodate the concept of
a texture that will only as image storage by the CPU, but it's cleaner
than it was.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The struct is still there though until all winsys layers are updated
|
|
|
|
Pass arguments properly in linux now. Still need to change this to use
a single calling convention on both platforms.
|
|
|
|
|
|
Using char * for labels doesn't work if you realloc the function
during assembly and free the old storage...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to the stack
|
|
|
|
release builds
|
|
|
|
|
|
|
|
|
|
|
