| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
These shaders are not st_vertex_shaders, but tgsi ureg shaders.
Fixes fd.o bug 25959.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Translate vertex shaders independently of fragment shaders.
Previously tried to make fragment shader semantic indexes always start
at zero and exclude holes. This was unnecessary but meant that vertex
shader translation had to be adjusted to take this into account.
Now use a fixed scheme for labelling special FS input semantics
(color, etc), and another fixed scheme for the generics.
With this, vertex shaders can be translated independently of the bound
fragment shader, assuming mesa has done its own job and ensured that
the vertex shader provides at least the inputs the fragment shader is
looking for. The state-tracker didn't attempt to do anything about
this previously, so it shouldn't be needed now.
|
| |
|
|
|
|
|
|
|
|
| |
Indicates whether there's defined image contents, or garbage/don't care.
This is set when we draw into a renderbuffer and cleared when we resize/
reallocate a renderbuffer or do a buffer swap (back buffer becomes undefined).
We use this to determine whether the front color buffer has been drawn to,
and whether to display its contents upon glFlush/Finish(), when the new
st_swapbuffers() function is used.
|
| | |
|
| |
|
|
| |
We can simplify this now that we no longer have any dynamic atoms.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
needed
The default texture is used when the current fragment shader has texture
sample instructions but the user has not provided/bound a texture.
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, we were sometimes rendering into a stale texture because
st_finalize_texture() would discard the old texture and create a new one.
Moved st_update_framebuffer atom after texture validation so that we
can create a new renderbuffer surface if the texture changes.
Also, split texture validation into two parts: finalize_textures and
update_textures. Do finalize_textures first to avoid getting into the
situtation where we're doing a pipe->surface_copy() mid-way through
state validation.
Some debug code still in place, but disabled...
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If we run out of texture memory we may not have the texture needed by the
fragment shader. If this happens, plug in a color passthrough shader.
So instead of crashing, we just don't see the texture.
GL_OUT_OF_MEMORY is raised, of course.
|
| |
|
|
|
| |
If texturing happens to be enabled when glBitmap() is called, need to be
careful about choosing a sampler unit, etc.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Move init of these items to new st_init_clear().
|
| |
|
|
|
| |
Bitmaps can extend beyond window edges so we need to clip.
Also, move some state atom vars to st_context to be a bit more efficient.
|
| |
|
|
|
|
|
| |
The bitmap cache attempts to accumulate a series of glBitmap calls in a
buffer to effectively render a whole bunch of bitmaps at once.
The cache can be disabled, if needed, by setting UseBitmapCache=GL_FALSE.
|
| | |
|
| |
|
|
|
| |
Also, glBitmap now re-uses the vertex buffer to avoid frequent allocations/
deallocations. And, use u_simple_shaders utility code.
|
| |
|
|
| |
Quad clears should be a little more efficient now.
|
| |
|
|
| |
This avoids the Mesa->TGSI translation step.
|
| |
|
|
|
|
|
| |
(blit, gen-mipmaps, quad-clear, etc)
Also, additional cso_set_*() functions for viewport, framebuffer, blend color,
etc. state.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Use the code in cso_context.c rather than st_cache.c.
Basically, binding of state objects now goes through the CSO module.
But Vertex/fragment shaders go through pipe->bind_fs/vs_state() since they're
not cached by the CSO module at this time.
Also, update softpipe driver to handle NULL state objects in various places.
This happens during context destruction. May need to update other drivers...
|
| |
|
|
|
| |
Bind all the samplers/textures at once rather than piecemeal.
This is easier for drivers to understand.
|
| |
|
|
|
| |
This is a better fix for the previous check-in.
Fixes texadd.c conform test, and probably other bugs.
|
| |
|
|
|
|
|
|
| |
Calling glTexSubImage() or glTexImage() to replace texture data didn't
reliably cause pipe->set_sampler_texture() to get called so drivers didn't
always get notified of new texture data.
The st_texture_object->pt pointer doesn't always indicate changed data so
added a dirtyData field.
|
| |
|
|
| |
This fixes potential problems with multi-context programs.
|
| |
|
|
|
|
|
| |
The state tracker will call pipe->get_paramf(PIPE_CAP_BITMAP_TEXCOORD_BIAS)
to get a bias factor for adjusting the texcoords used in bitmap/drawpixels.
This allows us to compensate for small differences in rasterization from
one device to another.
|
| |
|
|
|
|
| |
The properties of a buffer represented by struct pipe_buffer_handle are now
basically constant over its lifetime. The state tracker gets to deal with any
more complex buffer semantics it may need to provide.
|
| |
|
|
|
|
|
|
| |
The CSO returned by pipe->create_vs_state() can't be passed to the
private draw module. That was causing glRasterPos to blow up.
Add a 'draw_shader' field to st_vertex_program for use with the private
draw module.
Change st_context->state.vs type from cso_vertex_shader to st_vertex_program.
|
| |
|
|
|
|
|
|
|
|
|
| |
If an app never called glViewport, the viewport size was always 0 by 0 pixels.
Now pass initial size to st_create_framebuffer() and initialize the viewport
and scissor bounds in st_make_current().
This could also be fixed by ensuring the gl_framebuffers passed to
_mesa_make_current() were initialized to the right size. But that involves
allocating the renderbuffers/pipe_surfaces earlier and that runs into some
other issues ATM.
Also remove obsolete createRenderbuffers param to st_create_framebuffer().
|
| | |
|
| |
|
|
|
| |
The effect of this mapping can be acheived by the state tracker and
setting up the pipe texture state pointers to incorporate its affects.
|
| | |
|
| |
|
|
|
| |
Something similar will return when geometry shaders are added, but for now
this interface is not required.
|
| |
|
|
|
| |
Directly use struct pipe_buffer_handle for storage and struct pipe_surface for
(un)mapping.
|
| |
|
|
| |
pipe->get_tex_surface() has to be used for access to texture image data.
|
| | |
|
