| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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().
|
|
s/FRAG_RESULT_DEPR/FRAG_RESULT_DEPTH/
s/FRAG_RESULT_COLR/FRAG_RESULT/COLOR/
Remove FRAG_RESULT_COLH (NV half-precision) output since we never used it.
Next, we might merge the COLOR and DATA outputs (COLOR0, COLOR1, etc).
|
|
Saves code, and will simplify future interface changes.
|
|
Conflicts:
src/mesa/state_tracker/st_cb_accum.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
|
Fixes glReadPixels, gl(Copy)TexSubImage, glCopyPixels.
|
|
|
|
Use _mesa_malloc(), _mesa_free(), etc everywhere, not malloc(), free(), etc.
Still using CALLOC_STRUCT() at this point.
|
|
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.
|
|
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.
|
|
Patch provide by Keith.
Used in state tracker by DrawPixels to indicate that the state tracker (driver)
is using its own vertex program. This prevents the texenvprogram code from
replacing conventional shader inputs with state vars.
Fixes glDraw/CopyPixels regressions.
|
|
We want to use the pipe_buffer_* inlines everywhere, but a pipe context
is not always available nor is it needed.
|
|
Also, rename p_tile.[ch] to u_tile.[ch]
|
|
In some cases, the vertex program output's semantic info didn't match up
with the fragment program's input semantic info. This info is now explicitly
passed into the st_translate_fragment_program() function.
|
|
|
|
|
|
You don't need a pipe_context * for this, and all other necessary info is
already inside pipe_surface.
|
|
The chars-per-pixel concept falls apart with compressed and yuv images,
where more than one pixel are coded in a single data block.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Create different temporary surfaces for CPU_READ/WRITE when needed (such as
for glReadPixels, glAccum, some glCopy/DrawPixels, glCopyTexSubImage, etc).
|
|
|
|
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.
|
|
|
|
This allows us to remove most of the direct references to winsys in the state tracker.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes the case where the app calls SwapBuffers then calls glReadPixels
to read the front color buffer. We now keep track of when the front buffer
is a _logically_ copy of the back buffer (after SwapBuffers) and read from
the back color buffer instead of the front.
|
|
|
|
Also, make sure that field is copied/updated in the program clone and combine functions.
Without this we weren't getting SAMP declarations in the TGSI shaders.
|
|
|
|
|
|
The cell driver still uses an internal CELL_FLUSH_WAIT flag, in the long run
proper fencing should be implemented for it.
|
|
|
|
|
|
We always need to do PBO validation, so do that in core Mesa before calling driv
er routine.
cherry-picked from Mesa/master.
|
|
At this time there are no optimizations for directly blitting between
buffer objects and surfaces (always go through mappings).
glean pbo test passes now
|
