| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 815cdcfbc0740c66b901361620c88d99541bdad2)
|
|
(cherry picked from commit 74b14fe6ddbece8bc662aac4d3b2b18d8d853486)
|
|
|
|
|
|
|
|
|
|
|
|
Move _glapi_proc typedef from glapitable.h to glapi.h
Also, don't include glapitable.h from glapi.h
Before we were including the huge glapitable.h file in every .c file.
|
|
|
|
|
|
Also, check the FEATURE flags in many places.
(cherry picked from commit 40d1a40f294f1ed2dacfad6f5498322fc08cc2d1)
Conflicts:
src/mesa/main/config.h
src/mesa/main/context.c
src/mesa/main/texobj.c
src/mesa/main/texstate.c
src/mesa/main/texstore.c
|
|
|
|
(cherry picked from commit 4be7296bfcba22a849f949d105ea385e6964cc25)
|
|
(cherry picked from commit 5f91007f996d0b7e3233f221a6b0056203e356d2)
|
|
(cherry picked from commit b36e6f0baf64491772b8e1a1cddf68a7dcf8ee22)
|
|
|
|
Basically, set up no-op Delete() methods for the DummyFrame/Renderbuffer objects.
|
|
When purging the program hash table, the refcount _should_ be one since
the program is referenced by the hash table. Need to explicitly set to
zero before calling delete().
Also, purge high-level shader hash tables before low-level program hash tables.
|
|
Use _mesa_reference_vert/fragprog() wherever we assign program pointers.
Fixes a memory corruption bug found with glean/api2 test.
|
|
|
|
shader/shader program objects to avoid memory access error.
|
|
This reverts commit 3ffd11f71d021f672b9bc15b3c39c155a0e2fecb.
|
|
|
|
|
|
Currently a callback delete_shader_cb is used for deleting shader
and shader program objects. Mesa detaches all attached shaders in
_mesa_free_shader_program_data when deleting shader program objects. However
it is likely that these shaders have been freed in _mesa_free_shader,
which will result in unexpected behaviour. This fix uses a single callback for
shader program objects and deletes shader program objects before shader objects.
|
|
|
|
|
|
|
|
This fixes the X server crash reported by KeithP on Aug 29.
The old context's FBOs will be unreferenced during context destruction so
there's no memleak with this change.
|
|
group's objects (Shane Blackett)
|
|
|
|
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.
|
|
|
|
Free FBOs before textures since the later may be referenced by the former.
Need to bind the context we're destroying if there isn't a current context
so that ctx->DeleteTexture() etc can be used.
|
|
|
|
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.
|
|
|
|
the framebuffer objects attached to drawables can have invalidate state
associated with them, since for the window framebuffer this is per-context
state and not per-fbo state. Since drivers rely on that information
(otherwise would need to check if currently the window-framebuffer is
bound in a lot of places) fix it up in _mesa_make_current (ugly).
(Brought over from i915tex_privbuffers, where it fixes xdemos/wincopy
when switching to front buffer rendering.)
|
|
of -I flags.
|
|
an app issue, not a mesa bug.
|
|
|
|
Shadow sampling from texture arrays is still not implemented. Everything
else should be there, though.
|
|
|
|
|
|
constants.
Previously, this limited us to 12 temp regs for vertex programs. Many vertex
shaders could exceed that. This forces us to stop using t_vb_arbprogram.c
for now because of its particular register indexing scheme. Need to increase
bits allocated for register indexing, etc.
|
|
|
|
|
|
Was removed during glsl-compiler work. Still need to go back and revisit this
because of the interaction with fragment shaders...
|
