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().
Front buffer rendering works as it stands but it completely
wrong. But as it stands fake front buffer rendering is
completely broken. So we keep it as it is. But lets atleast
handle it in the get buffers code.
When a hw driver fell back to swrast, swrast wasn't always getting informed
of program changes. When fixed function is translated into shaders, flags
like _NEW_LIGHT, _NEW_TEXTURE, etc. should really signal _NEW_PROGRAM.
In this case, swrast wasn't seeing _NEW_PROGRAM when new fragment shaders
were generated.
Previously would have to allocate a new VBO after firing a draw command
as subsequent call to Map() on old VBO might block if the driver had
submitted the commands to hardware.
Will be needed in coming GL extensions (GL_map_buffer_range, GL 3.0).
Will be used by the vbo module to avoid reallocating vbo's at each
draw primitive call.
This was based of the unfinnished code that Keith
Whitwell started on but never finnished. I moved
the code from the glx directory because dri drivers
can be used for more things then just glx.
It seems that XGetImage() from a depth 32 TrueColor window is flakey.
Drawing with XPutImage() instead of XPutPixel() seems to work better, but
still not perfectly.
Keep using the original code for now until more is learned.
Need to clear the _ReallyEnabled field before possibly continuing the loop.
Also, set _Current pointer to NULL if the unit is no longer enabled.
Fixes piglit lodbias regression
For regular GL, we must have vertex positions in order to draw. But ES2
doesn't have that requirement (positions can be computed from any array
of data).
See bug 19911.
