| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
src/mesa/drivers/dri/radeon/radeon_fbo.c
src/mesa/drivers/dri/s3v/s3v_tex.c
src/mesa/drivers/dri/s3v/s3v_xmesa.c
src/mesa/drivers/dri/trident/trident_context.c
src/mesa/main/debug.c
src/mesa/main/mipmap.c
src/mesa/main/texformat.c
src/mesa/main/texgetimage.c
|
|
Uf. Lots of files touched. Would people with working vega, xorg, dri1, etc.
please make sure you are not broken, and fix yourself up if you are.
There were only two or three places where the code did not have painful
fallbacks, so I would advise st maintainers to find less painful workarounds,
or consider overhauling util_surface_copy and util_surface_fill.
Per ymanton, darktama, and Dr_Jakob's suggestions, clear has been left as-is.
I will not add PIPE_CAP_BLITTER unless it is deemed necessary.
|
|
_ActualFormat is replaced by Format (MESA_FORMAT_x).
ColorEncoding, ComponentType, RedBits, GreenBits, BlueBits, etc. are
all replaced by MESA_FORMAT_x queries.
|
|
These don't depend on context state, but use a screen pointer.
|
|
Conflicts:
src/gallium/auxiliary/util/u_cpu_detect.c
|
|
Otherwise st_copy_texsubimage will fallback to software blit due to
inconsistent base formats.
|
|
|
|
|
|
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
If a texture image is bound to a framebuffer for render-to-texture, but
the hardware doesn't support rendering to its internal format,
report the framebuffer as incomplete with FRAMEBUFFER_UNSUPPORTED.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
Conflicts:
src/mesa/state_tracker/st_cb_fbo.c
src/mesa/state_tracker/st_framebuffer.c
|
|
The existing implementation was already implemented on software, but relied
on the pipe driver to always support the R16G16B16A16_SNORM format. This
patch eliminates that, without prejudice against a future hardware-only
implementation.
It also avoids some of the short <-> float conversions, and only does a read
transfer of the color buffer on GL_RETURN if absolutely necessary.
|
|
|
|
Previously we created the pipe_surface during framebuffer validation.
But if we did a glCopyTex[Sub]Image() before anything else we wouldn't yet
have the surface. This fixes that.
|
|
When we create a new front color buffer (user called glDrawBuffer(GL_FRONT))
initialize it to the contents of the back buffer. Any previous call to
SwapBuffers() would have done that in effect, so make it reality.
|
|
Indicates whether there's defined image contents, or garbage/don't care.
This is set when we draw into a renderbuffer and cleared when we resize/
reallocate a renderbuffer or do a buffer swap (back buffer becomes undefined).
We use this to determine whether the front color buffer has been drawn to,
and whether to display its contents upon glFlush/Finish(), when the new
st_swapbuffers() function is used.
|
|
Before we always created the front color buffer, even if was never used.
This can save some memory.
|
|
|
|
|
|
|
|
The core reference counting code is centralized in p_refcnt.h.
This has some consequences related to struct pipe_buffer:
* The screen member of struct pipe_buffer must be initialized, or
pipe_buffer_reference() will crash trying to destroy a buffer with reference
count 0. u_simple_screen takes care of this, but I may have missed some of
the drivers not using it.
* Except for rare exceptions deep in winsys code, buffers must always be
allocated via pipe_buffer_create() or via screen->*buffer_create() rather
than via winsys->*buffer_create().
|
|
Not needed since renderbuffers are ref-counted.
Fixes progs/demos/shadowtex.
|
|
Gallium only supports combined depth/stencil buffers, not separate ones.
If the user tries to create create a FBO with separate depth/stencil
renderbuffers mark the FBO as unsupported.
|
|
Conflicts:
src/mesa/state_tracker/st_cb_accum.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
|
|
|
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
|
|
Instead, a new pipe_transfer object has to be created and mapped for
transferring data between the CPU and a texture. This gives the driver more
flexibility for textures in address spaces that aren't CPU accessible.
This is a first pass; softpipe/xlib builds and runs glxgears, but it only shows
a black window. Looks like something's off related to the Z buffer, so the
depth test always fails.
|
|
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.
|
|
|
