Age | Commit message (Collapse) | Author |
|
|
|
Use _mesa_malloc(), _mesa_free(), etc everywhere, not malloc(), free(), etc.
Still using CALLOC_STRUCT() at this point.
|
|
Merge commit 'origin/gallium-0.2' into gallium-master-merge
Conflicts:
Makefile
docs/relnotes-7.4.html
docs/relnotes.html
src/mesa/drivers/dri/i965/brw_wm.h
src/mesa/main/imports.c
src/mesa/main/mtypes.h
src/mesa/main/texcompress.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_save_draw.c
|
|
this change disassociates, at least from the driver perspective,
the surface from buffer. surfaces are technically now views on the
textures so make it so by hiding the buffer in the internals of
textures.
|
|
move it to pipe/internal/p_winsys_screen.h and start converting
the state trackers to the screen usage
|
|
|
|
|
|
|
|
Quite a few util modules were maintaining a single vertex buffer over multiple
frames, and potentially reusing it in subsequent frames. Unfortunately that
would force us into syncrhonous rendering as the buffer manager would be
forced to wait for the previous rendering to complete prior to allowing the
map.
This resolves that issue, but requires the state tracker to issue a few new
flush() calls at the end of each frame.
|
|
|
|
|
|
|
|
The chars-per-pixel concept falls apart with compressed and yuv images,
where more than one pixel are coded in a single data block.
|
|
|
|
|
|
|
|
|
|
Before, we were sometimes rendering into a stale texture because
st_finalize_texture() would discard the old texture and create a new one.
Moved st_update_framebuffer atom after texture validation so that we
can create a new renderbuffer surface if the texture changes.
Also, split texture validation into two parts: finalize_textures and
update_textures. Do finalize_textures first to avoid getting into the
situtation where we're doing a pipe->surface_copy() mid-way through
state validation.
Some debug code still in place, but disabled...
|
|
Create different temporary surfaces for CPU_READ/WRITE when needed (such as
for glReadPixels, glAccum, some glCopy/DrawPixels, glCopyTexSubImage, etc).
|
|
|
|
|
|
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.
|
|
|
|
This allows us to remove most of the direct references to winsys in the state tracker.
|
|
Make sure we can really render to the texture surface given its format.
|
|
|
|
Also clarify that RGB formats with no (used) alpha component are treated as
having alpha = 1.0.
|
|
If the driver can't create a PIPE_FORMAT_R16G16B16A16_SNORM surface, create
an accum surface using a shallower format and taller height. Since only the
accum buffer code accesses the surface the actual format doesn't really
matter, just that there's enough memory.
|
|
|
|
The cell driver still uses an internal CELL_FLUSH_WAIT flag, in the long run
proper fencing should be implemented for it.
|
|
These functions are now per-screen, not per-context.
|
|
Calling glTexSubImage() or glTexImage() to replace texture data didn't
reliably cause pipe->set_sampler_texture() to get called so drivers didn't
always get notified of new texture data.
The st_texture_object->pt pointer doesn't always indicate changed data so
added a dirtyData field.
|
|
Provide an actual definition of the pipe_buffer struct, containing
the parameters used to create the buffer, and its refcount.
Shift refcounting buffers out of the winsys interface, similar to
surfaces & textures.
Rework pipebuffer/ to reflect the fact these changes, and also Michel's
reworking of the buffer interface.
|
|
These are changes that are in our internal branch, but somehow were skipped
so far. It was done using visual comparison of the branches --
it is likely that changes are being carried on the wrong way
|
|
It's now the responsibility of surface users to keep track of their mappings.
|
|
|
|
|
|
st_create_framebuffer() now takes pipe_formats for the color, depth, stencil
buffers.
This avoids a round-about chain of calls to pipe->is_format_supported() for
window renderbuffers (their format never changes).
Renderbuffer format selection code in st_format.c is simpler now too.
|
|
|
|
|
|
surface, etc.
Additional types may be added in the future.
|
|
intel_winsys works again.
|
|
|
|
This makes debugging a _lot_ easier.
In gdb, "print format" used to display 613570600, now you see PIPE_FORMAT_A8R8G8B8_UNORM.
|
|
|
|
Directly use struct pipe_buffer_handle for storage and struct pipe_surface for
(un)mapping.
|
|
pipe->get_tex_surface() has to be used for access to texture image data.
|
|
|