| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
src/gallium/auxiliary/cso_cache/cso_context.c
src/gallium/auxiliary/util/u_blit.c
src/gallium/auxiliary/util/u_gen_mipmap.c
src/gallium/drivers/i915/i915_context.h
src/gallium/drivers/i965/brw_draw_upload.c
src/gallium/drivers/r300/r300_blit.c
src/gallium/drivers/r300/r300_context.h
src/gallium/drivers/r300/r300_render.c
src/gallium/drivers/r300/r300_state_derived.c
src/mesa/state_tracker/st_cb_bitmap.c
src/mesa/state_tracker/st_cb_clear.c
|
|
|
|
Needs testing.
|
|
This is a property of the associated src_format pipe format.
Hence use util_format_get_nr_components to query this when necessary instead.
|
|
saves us a dword in sampler state, hw can't do non-integer aniso degree anyway.
To allow aniso 1x (which seems of dubious value but some hardware (radeons)
have such a mode, and even d3d allows specifiying it) redefine anisotropic
filtering as disabled only if max_anistropy is 0.
|
|
More consistent with other state data, might allow some compilers to pack
the struct better (doesn't matter for gcc).
|
|
This will make driver's life a bit harder, however it makes sense that stencil
reference value is not part of the pipe_depth_stencil_alpha_state, because
it often (there are some algorithms which require this) changes more frequently
than the rest of the dsa state. This is also encouraged by some graphic APIs.
Treat it similar to pipe_blend_color.
|
|
Conflicts:
src/gallium/drivers/nv10/nv10_state.c
src/gallium/drivers/nv20/nv20_state.c
src/gallium/drivers/nv50/nv50_program.c
|
|
|
|
This determines if points should be rasterized according to GL point rules
or as normal quads (GL point sprites / d3d points / d3d point sprites).
|
|
Don't need sprite coord origin per coord.
Also, don't need separate sprite enable bit - if all coords have it diabled,
then there are no point sprites (technically, there's a distinction in pre-GL3,
but it only differs in having more leniency in clamping to max size, something
the state tracker would need to handle and the hardware won't bother anyway).
Also, use packed field for the per-coord enables.
All in all, should save 3 dwords in rasterizer state (from 10 down to 7).
|
|
|
|
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_screen.c
src/gallium/include/pipe/p_defines.h
|
|
|
|
|
|
GL 3.0 (EXT_draw_buffers2) and other APIs allow independent blend enables and
write masks per render target, ARB_draw_buffers_blend (and other APIs) also
allow independent blend functions. Things like dithering, logic ops however
are not extended to be per rendertarget, that might be conceptually possible
however it doesn't look like any API wants to expose this.
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_draw_arrays.c
src/mesa/state_tracker/st_draw_feedback.c
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_draw_arrays.c
|
|
Other struct types (like pipe_texture) are referenced before they're
defined so no reason to special-case this one.
|
|
The state tracker is responsible for clamping to any graphics API enforced
size min/max limits for both the static point_size setting as well as per
vertex point size (in the vertex shader).
Note that mesa state tracker didn't actually use these values.
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/gallium/state_trackers/xorg/xorg_exa.c
|
|
Historically, parts of mesa code are not strict-aliasing safe, hence
-fno-strict-aliasing is needed to compile (this got forgotten for scons
builds for gallium, which indeed not only caused compiler warnings but also
unexplicable crashes in non-debug builds). However, we should try to eliminate
code not complying with strict-aliasing code at least for gallium.
Hence change pipe_reference functions to make them strict-aliasing compliant.
This adds a bit more complexity (especially for derived classes) but is the
right thing to do, and it does in fact fix a segfault.
|
|
Previously, gallium shared sampler and texture state between vertex
and fragment shader stages. This change generalises this concept by
providing separate entrypoints for vertex and fragment sampler state
setting.
A new capability bit is added to query the driver for the number
of samplers that can be utilised by a vertex and fragment shader
at the same time.
|
|
This patch removes nblocksx, nblocksy arrays from pipe_texture (can be
recalculated if needed). Furthermore, pipe_format_block struct is gone
completely (again, contains just derived state).
nblocksx, nblocksy, block are also removed from pipe_transfer, together with
the format enum (can be obtained from the texture associated with the transfer).
|
|
|
|
This was redundant as drivers can just keep track of whether they are
inside a begin/end query pair. We want to add more query types later
and also support nested queries, none of which map well onto a flag like
this. No driver appeared to be using the flag.
|
|
|
|
|
|
plus it saves us a cacheline in the cso
|
|
This was only present for the sake of GL_ARB_shadow_ambient which we
never implemented in Gallium. If we someday want GL_ARB_shadow_ambient
we can implement it in the state tracker by adding a MAD after the
relevant TEX instructions.
|
|
The format field encodes compressed vs. uncompressed already. We can easily
check if a texture is compressed with pf_is_compressed(texture->format).
|
|
|
|
|
|
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.
|
|
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().
|
|
Conflicts:
src/mesa/state_tracker/st_cb_accum.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
|
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.
|
|
Not used in p_state.h but used in p_context.h and p_screen.h
|
|
this change disassociates, at least from the driver perspective,
the surface from buffer. surfaces are technically now views on the
textures so make it so by hiding the buffer in the internals of
textures.
|
|
reuse the size of the actual buffer
|
|
|
|
|
|
|
|
|
|
This commit is mostly just a cosmetic change that cleans-up the interfaces,
replacing pipe_winsys::surface_* calls by
/**
* Allocate storage for a display target surface.
*
* Often surfaces which are meant to be blitted to the front screen (i.e.,
* display targets) must be allocated with special characteristics, memory
* pools, or obtained directly from the windowing system.
*
* This callback is invoked by the pipe_screenwhen creating a texture marked
* with the PIPE_TEXTURE_USAGE_DISPLAY_TARGET flag to get the underlying
* buffer storage.
*/
struct pipe_buffer *(*surface_buffer_create)(struct pipe_winsys *ws,
unsigned width, unsigned height,
enum pipe_format format,
unsigned usage,
unsigned *stride);
Most drivers were updated but not all were tested. Use the softpipe pipe
driver and the xlib winsys changes as a reference when fixing other drivers.
|
