Age | Commit message (Collapse) | Author |
|
|
|
|
|
This was used to indicate OpenGL's lower-left origin for fragment window
coordinates for polygon stipple and gl_FragCoord.
Now:
- fragment coordinate origin is always upper-left corner
- GL polygon stipple is inverted and shifted before given to gallium
- GL fragment programs that use INPUT[WPOS] are modified to use an
inverted window coord which is placed in a temp register.
Note: the origin_lower_left field still exists in pipe_rasterizer_state.
Remove it when all the drivers, etc. no longer reference it.
|
|
|
|
|
|
This function is called from many OS-dependent versions of MakeCurrent.
Move the check for multithreading to this central location to avoid
having to make this check from all the callers.
|
|
Fixes progs/tests/tri-fbo-tex-mip.c
|
|
|
|
|
|
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
The draw module provides a similar interface to the driver which
is retained as various bits of hardware may be able to take on
incremental parts of the vertex pipeline. However, there's no
need to advertise all this complexity to the state tracker.
There are basically two modes now - normal and passthrough/screen-coords.
|
|
Any driver who needs a copy of the shader tokens must organize to
do so itself. This has been the case for a long time, but there
was still defensive code in the state tracker, which is now removed.
Any bugs resulting from this need to be fixed in the offending driver...
|
|
Not sure if this indicates a problem elsewhere, but without this check
trivial/tri-fbo.c segfaults on resize. With the patch, it renders
correctly.
|
|
It is not the state tracker's responsibilty to inject sleeps and
pessimize performance in the hope of avoiding buffer synchronization
issues in buggy drivers.
Calling finish() here will just hide problems that need to be fixed
elsewhere.
|
|
I should have gotten most uses and implementation
correctly fixed, but things might break.
Feel free to blame me.
|
|
|
|
|
|
Silences warnings with 64-bit builds. See comments for details.
|
|
|
|
|
|
A bit of refactoring with an eye toward ES2 and GL 3.1
|
|
|
|
|
|
Namelly, FlushMappedBufferRange takes a subrange relative to the original
range.
|
|
|
|
|
|
|
|
|
|
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().
|
|
Not needed since renderbuffers are ref-counted.
Fixes progs/demos/shadowtex.
|
|
|
|
Conflicts:
scons/gallium.py
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/gallium/include/pipe/p_defines.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_exec_draw.c
|
|
Using PIPE_BUFFER_USAGE_DONTBLOCK.
|
|
|
|
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).
|
|
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
Need to check ctx->DrawBuffer->Visual.stencilBits not ctx->Visual.stencilBits
because the later only applies to the window system buffers, not user-created
FBOs.
This, plus the previous commit, fixes progs/tests/fbotexture.c
|
|
Gallium only supports combined depth/stencil buffers, not separate ones.
If the user tries to create create a FBO with separate depth/stencil
renderbuffers mark the FBO as unsupported.
|
|
Also don't send the partial program fragment down to hardware -- the
program will never be used in that form.
|
|
Saves code, and will simplify future interface changes.
|
|
|
|
|
|
|
|
|
|
This trims down and cleans up imports.h and glheader.h quite a bit.
|
|
Use loops to consolidate lots of texture object code.
|
|
instructions
These texture types were defined but never put to use.
For the time being though, the Mesa->TGSI translater isn't emitting these
targets. See the XXX comment in map_texture_target().
|
|
Since Ian's patch of a few weeks ago, we can enable all three variations
of two-sided stencil. Update the state tracker to handle the extra back-
face state and turn on the EXT.
Note: there's a new Glean test for two-sided stencil now...
|
|
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_tile_cache.c
|