| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intel sometimes uses packed depth/stencil buffers even when only a depth
buffer or only a stencil buffer was requested. Common code currently
uses the _BaseFormat field to determine whether a depth/stencil wrapper
is necessary. But unless the user explicitly requested a packed
depth/stencil buffer, the _BaseFormat field does not encode this
information, and the required wrappers are not created.
The problem was introduced by commit 45e76d2665b38b ("mesa: remove a
bunch of gl_renderbuffer fields"), which killed off the _ActualFormat
field upon which the decision to create a wrapper used to be made. This
patch changes the logic to use the Format field instead, which is more
like the old code.
Fixes fdo bug 27590.
Signed-off-by: Nick Bowler <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
Drivers still reject them today, but cairo would like to use these.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This must always be true now, so there is no reason to check it. Ever.
Signed-off-by: Ian Romanick <[email protected]>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This should make things easier for drivers wanting to work with a
"subclass" of gl_framebuffer.
The complementary "_mesa_initialize_framebuffer" function is now
called "_mesa_initialize_window_framebuffer" for the sake of
symmetry.
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The assertion is that the correct read type to be using is the native
type of the underlying read renderbuffer. For some fallback paths, this
may be worse than GL_RGBA/GL_UNSIGNED_BYTE for reads today, but it gets
all drivers the expected GL_BGRA/GL_UNSIGNED_BYTE for ARGB8888 or
GL_BGR//GL_UNSIGNED_SHORT_5_6_5_REV for rgb565 with no work.
This fixes the intel (and other) DRI drivers to report read formats that
should hit blit PBO readpixels paths.
|
| |
|
|
|
|
| |
_ActualFormat is replaced by Format (MESA_FORMAT_x).
ColorEncoding, ComponentType, RedBits, GreenBits, BlueBits, etc. are
all replaced by MESA_FORMAT_x queries.
|
| | |
|
| |
|
|
| |
Also, update comments.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
_mesa_reference_renderbuffer()
_mesa_unreference_framebuffer() is deprecated since _mesa_reference_framebuffer(ptr, NULL)
can be used instead.
|
| |
|
|
|
|
|
| |
Update the visual info in the _mesa_test_framebuffer_completeness()
function when we've determined the FBO to be "complete".
Fixes regression seen in progs/demos/shadowtex.c
|
| |
|
|
|
|
| |
When we change a FBO's attachments, set _Status=0.
Before using an FBO, check if status != GL_FRAMEBUFFER_COMPLETE.
Also, fix missing GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE status.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
framebuffer.c
(cherry picked from commit 9091015a9782ad15e58540a8fd61df83ea2bfe31)
|
| | |
|
| |
|
|
|
| |
Set _ColorDrawBuffers[0] = NULL if no renderbuffers enabled.
Check that _ColorDrawBuffers[0] is non-null before dereferencing in a few places.
|
| |
|
|
|
|
|
| |
Each array element is now a BUFFER_x token rather than a BUFFER_BIT_x bitmask.
The number of active color buffers is specified by _NumColorDrawBuffers.
This builds on the previous DrawBuffer changes and will help with drivers
implementing GL_ARB_draw_buffers.
|
| |
|
|
|
|
|
|
|
|
|
| |
These fields are no longer indexed by shader output. Now, we just have
a simple array of renderbuffer pointers.
If the shader writes to gl_FragData[i], send those colors to the N
_ColorDrawBuffers. Otherwise, replicate the single gl_FragColor (or
the fixed-function color) to the N _ColorDrawBuffers.
A few more changes and simplifications can follow from this...
|
| |
|
|
|
|
|
|
|
| |
previously did.
Basically, in update_framebuffer() (which should be called after an FBO is bound
with MakeCurrent or BindFramebuffer) we check if the FBO is a window-system FBO.
If it is, update the FBO's GL_READ/DRAW_BUFFER state according to the context state.
Old code still in place but disabled with #if 0 / #endif.
|
| | |
|
| |
|
|
|
|
| |
Use new _mesa_reference_texobj() function for referencing/unreferencing
textures. Add new assertions/tests to try to detect invalid usage of
deleted textures.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Conflicts:
src/mesa/main/framebuffer.c
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
In xmesa_check_and_update_buffer_size() handle xmctx==NULL correctly: still
call _mesa_resize_framebufer(). If we don't we can wind up in a situation
where the framebuffer size is non-zero but an attached renderbuffer size
is still initialized to zero. This inconsistancy can later cause problems.
Check for zero-size renderbuffers in update_color_draw_buffers() and
update_color_read_buffer().
See bug 7205.
|
| | |
|
| |
|
|
|
|
|
| |
Use _mesa_reference_framebuffer() and _mesa_unreference_framebuffer() functions
to be sure reference counting is done correctly. Additional assertions are
done too. Note _mesa_dereference_framebuffer() renamed to "unreference" as
that's more accurate.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Also, added DeletePending field to gl_framebuffer used when a window has been
deleted, but there still may be rendering contexts attached to the
gl_framebuffer object.
|
| |
|
|
|
| |
module updates its state (CLIP_BIT) upon resizes. The driver could do this
instead, but doing it here is safer.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
decrement, delete and locking.
|
| | |
|
