| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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
|
| | |
| |
| |
| | |
Not used in p_state.h but used in p_context.h and p_screen.h
|
| |/
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
So that the previously anonymous depth/stencil/alpha structures can be
identified in the traces.
This is just syntactic sugar: it does not break source or binary compatibility.
|
| | |
|
| | |
|
| |
|
|
|
| |
The chars-per-pixel concept falls apart with compressed and yuv images,
where more than one pixel are coded in a single data block.
|
| | |
|
| | |
|
| |
|
|
| |
And don't use the display-target path to allocate them.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Allocate a texture containing storage instead.
Also clean up ACCUM buffer allocation slightly -- drivers will need
some changes to texture allocation logic to accomodate the concept of
a texture that will only as image storage by the CPU, but it's cleaner
than it was.
|
| |
|
|
| |
pointing at
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously all drivers were in twosided mode since they checked for
stencil.enable[1] flag which was a copy of stencil.enable[0]. Note that drivers
should not reference stencil[1] state (other than the enable) if twosided
stenciling is disabled (for now the stencil state is still copied but for
instance clear_with_quads won't provide useful values in there).
Also, use _TestTwoSide instead of TestTwoSide since results would be
bogus otherwise if using APIs with implicit two side stencil enable
(i.e. core ogl 2.0).
|
| |
|
|
|
|
|
| |
Use this to set up hardware rasterization (if your hardware can
do it) or otherwise turn on various tweaks in the draw module.
Currently only hooked up to point biasing code.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We need it to fulfil D3D minimum requirements.
|
| |
|
|
|
| |
The later follows the naming scheme of other limits.
Keep the old definition until all possible usage is updated.
|
| |
|
|
|
| |
This bit tells us which vertex of the primitive is used to
propagate color for the remaining vertices if flatshade mode.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Brian's patch to clean up the shader interfaces.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will allow creating textures before a rendering context exists, for example.
Only implemented in i915 driver for now. i915pipe->texture_create() just
dispatches through to the i915screen->texture_create() to avoid state tracker
changes for now.
|
| |
|
|
|
| |
Added pipe field to pipe_texture (temporary, see comments).
First step toward context-less texture creation...
|
