| Age | Commit message (Collapse) | Author |
|---|
|
This was broken with last merge see 62043b27575c378c027251316421e4699f461108
for explanations
|
|
This was broken with last merge see f48473e42511f8d37a239a07f791bc0a87209e5b
for explanations.
|
|
Basically the same as 43d9020ff1e975e7f4f9480d9ef24f0b9fb2141f for intel. Bug 21688.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
|
|
|
Conflicts:
src/mesa/drivers/dri/r200/r200_state.c
src/mesa/drivers/dri/r300/r300_context.h
src/mesa/drivers/dri/r300/r300_fragprog.c
src/mesa/drivers/dri/r300/r300_state.c
src/mesa/drivers/dri/r300/r300_texmem.c
src/mesa/drivers/dri/r300/r300_texstate.c
src/mesa/drivers/dri/r300/r500_fragprog.c
src/mesa/drivers/dri/radeon/radeon_screen.c
src/mesa/drivers/dri/radeon/radeon_state.c
|
|
|
|
Looking for memory leaks that were causing crashes in my environment
in a situation where valgrind would not work, I ended up improving
the i965 debug traces so I could better see where the memory was
being allocated and where it was going, in the regions and miptrees
code, and in the state caches. These traces were specific enough
that external scripts could determine what elements were not being
released, and where the memory leaks were.
I also ended up creating my own backtrace code in intel_regions.c,
to determine exactly where regions were being allocated and for what,
since valgrind wasn't working. Because it was useful, I left it in,
but disabled and compiled out. It can be activated by changing a flag
at the top of the file.
|
|
A temporary change to the intelMakeCurrent() function to make
it work with frame buffer objects causes the static regions
associated with the context (the front_region, back_region,
and depth_region) to take on an additional reference, with
no corresponding release. This causes a memory leak if a
program repeatedly creates and destroys contexts.
The fix is the corresponding hack, to unreference these
regions when the context is deleted, but only if the
framebuffer objects are still present and the same
regions are still referenced within.
Both sets of code have comment blocks referring to each
other.
|
|
When out of memory (in at least one case, triggered by a longrunning
memory leak), this code will segfault and crash. By checking for the
out-of-memory condition, the system can continue, and will report
the out-of-memory error later, a much preferable outcome.
|
|
The current texture for any particular texture unit is given an additional
reference in update_texture_state(); but if the context is closed before
that texture can be released (which is quite frequent in normal use, unless
a program unbinds and deletes the texture and renders without it to force
a call to update_texture_state(), the memory is lost.
This affects general Mesa; but the i965 is particularly affected because
it allocates a considerable amount of additional memory for each allocated
texture.
|
|
In addition to being HW accelerated, it avoids the incorrect
(black) rendering of the mipmaps that SW was doing in fbo-generatemipmap.
Improves the performance of the mipmap generation and drawing in
fbo-generatemipmap by 30%.
|
|
Make this be its own function for setup/teardown of the binding of these
texcoords. No performance difference in the engine demo (I just felt dirty
not using a VBO for this), and I think it should be more resilient to
interference from current GL state.
|
|
|
|
16 is the limit for now because of various 32-bit bitfields.
|
|
|
|
Link fails if too many varying vars.
|
|
|
|
They seem to be used for something else and using them for shader temps
seems to lead to GPU lock-ups.
Call _mesa_warning() when we run out of temps.
Also, clean up some debug code.
|
|
|
|
|
|
|
|
The src/dest x,y, and w,h arguments of the pipe->surface_copy
function are unsigned and the drivers aren't expecting negative
(or extremly-large unsigned) values as inputs. Trim the requests
at the state-tracker level before passing down.
|
|
Rendering should already have been flushed, any synchronization will
be done by the driver or memory manager.
|
|
Previously only non-indexed or indicies-in-a-vbo cases were handled in
this code. This change adds the missing regular indices-in-memory
case.
|
|
|
|
Fixes piglit/texdepth
|
|
- remove unused r300UpdateClipPlanes function
- move reg definition to r300_reg.h
- remove incorrect forward definition of tnl_UpdateFixedFunctionProgram and add proper #include
- remove unreachable code
|
|
|
|
|
|
Don't really delete vertex array objects until the refcount hits zero.
At that time, unbind any pointers to VBOs.
|
|
Every kind of object that can be shared by multiple contexts should be
refcounted.
|
|
|
|
Since shared array objects may point to the null/default buffer object,
the null/default buffer object should be part of the shared state.
|
|
|
|
No-op the bad drawing command rather than go out of bounds and render
garbage. Print a warning to alert the developer to the bad drawing call.
|
|
|
|
The flag is set when we data has been written into the buffer object.
|
|
Used to be done in the glVertex/Normal/Color/etc/Pointer() calls but
if the VBO was reallocated the size could change.
New _NEW_BUFFER_OBJECT state flag.
|
|
|
|
|
|
No difference, but a little more understandable.
|
|
Will be handy for bounds checking later...
|
|
|
|
|
|
|
|
|
|
|
|
And use GL_ELEMENT_ARRAY_BUFFER where appropriate.
|
|
|
|
|
