| Age | Commit message (Collapse) | Author |
|---|
|
This makes debugging a _lot_ easier.
In gdb, "print format" used to display 613570600, now you see PIPE_FORMAT_A8R8G8B8_UNORM.
|
|
|
|
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.
|
|
|
|
Also, in st_init_limits(), clamp driver's values against Mesa's internal limits.
|
|
program concatenation.
|
|
|
|
|
|
glDrawPixels.
|
|
do pixel transfer in the fragment program.
|
|
Basic code for PixelTranslfer ops and glDrawPixels works now.
A pixel transfer program is generated and combined with the current
fragment shader.
|
|
|
|
Move pipe_region/surface_reference functions to pipe/p_inlines.h.
Remove #include "p_util.h" from pipe/p_context.h.
|
|
The old supported_formats interface returned a list of formats
supported by a pipe/winsys implementation. This was reasonable
when gallium had a fixed list of predefined format.
Now things has changed and the definition of PIPE_FORMAT is
more flexible.
The new shiny is_format_supported interface gets PIPE_FORMAT
as an argument and returns a boolean whether this particular
format is supported.
|
|
|
|
This allows regions to be allocated w/out a rendering context.
|
|
The _rgba versions are temporary until the state tracker is updated.
|
|
|
|
For some drivers (like Xlib) it's not possible to treat the front/back color
buffers as pipe_regions. So pipe->region_copy() won't work. Added a new
state tracker field indicating if we can use regions for colorbuffer accesses.
This should probably be re-considered someday...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This controls whether texcoords are interpreted as-is or scaled up from [0,1].
Fixes glDrawPixels/glBitmap problems on i915 when image is non power-of-two.
Also, cleans up the CSO sampler state for i915 a bit.
|
|
|
|
|
|
|
|
|
|
|
|
for each fragment program.
|
|
|
|
|
|
|
|
Create a texture matching the bitmap image and use a fragment program
to modulate current raster color by the boolean-valued texture. Need to
eventually use fragment culling (see comments in code).
|
|
|
|
proper linking.
Previously, programs were translated independently during validation.
The problem is the translation to TGSI format, which packs shader
input/outputs into continuous slots, depends on which vertex program is
being paired with which fragment shader. Now, we look at the outputs
of the vertex program in conjunction with the inputs of the fragment shader
to be sure the attributes match up correctly.
The new 'linked_program_pair' class keeps track of the associations
between vertex and fragment shaders. It's also the place where the TGSI
tokens are kept since they're no longer per-program state but per-linkage.
Still a few loose ends, like implementing some kind of hash/lookup table
for linked_program_pairs.
|
|
|
|
state constant state object semantics.
|
|
|
|
Allow driver custom allocation within cached objects. The shaders
are currently twiced (by cso layer and by the program itself).
|
|
TGSI_ATTRIB_x tokens still present and used in a few places.
Expanded set of TGSI_SEMANTIC_x tokens for describing the meaning
of inputs/outputs. These tokens are in a crude state ATM.
Lots of #if 0 / disabled code to be removed yet, etc...
Softpipe and i915 drivers should be in working condition but not heavily tested.
|
|
Basically make cso hold the driver specific struct, while
managing the template.
|
|
Drivers can now create whatever they want from the state template. We
use cso_state object to store the template (necessary during lookups),
and the driver data. Convert blend state to the new semantics.
|
|
Create/Delete calls should be split since in create we'll be
compiling them so we want to know which one it is (vertex/fragment).
|
|
This is a step toward removing TGSI_ATTRIB_ tokens.
Basically, when translating Mesa programs to TGSI programs, pass in input and
output register re-maps, plus interpolation info.
There's some known breakage (cubemap.c) so more to be done...
|
|
|
