| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This reverts commit a6d17bf671d6bfbb187a62ba14b9ad08fb5dafe1.
|
|
|
|
|
|
|
|
A recent commit removed a bug which essentially caused a sync after each
use of a user buffer. In fixing it, the scratch area can now become
fragmented under some circumstances leading to nouveau_bo_tmp() waiting
forever for a large enough block of free space.
This fixes ppracer, gl-117 and probably a heap of other apps.
|
|
|
|
|
|
|
|
|
|
|
|
We need a way to specify the type of minification filter
used to downsample mipmap levels.
The old util_gen_mipmap() retains its behaviour and uses
LINEAR filter.
|
|
pipe cso's were being destroyed, but the hash elements themselves not.
proper fix is IMHO add a destructor callback to cso_hash.
|
|
Overcomplex and not much different from using a global variable...
|
|
|
|
There are no known tools for windows kernel memory debugging, so this is a
simple set of malloc etc wrappers.
Enabled by default on win32 debug builds
|
|
|
|
Middle-end elements are ushort, but prior to that have to treat all
elements as unsigned to avoid wrapping and/or overruns.
|
|
Trying to put a structure in place that we can actually optimize.
Initially just implementing a passthrough mode, this will fairly soon
replace all the vertex_cache/prim_queue/shader_queue stuff that's so
hard to understand...
Split the vertex processing into a couple of distinct stages:
- Frontend
- Prepares two lists of elements (fetch and draw) to be processed
by the next stage. This stage doesn't fetch or draw vertices, but
makes the decision which to draw. Multiple implementations of this
will implement different strategies, currently just a vcache
implementation.
- MiddleEnd
- Takes the list of fetch elements, fetches them, runs the vertex
shader, cliptest, viewport transform on them to produce a
linear array of vertex_header vertices.
- Passes that list of vertices, plus the draw_elements (which index
into that list) onto the backend
- Backend
- Either the existing primitive/clipping pipeline, or the vbuf_render
hardware backend provided by the driver.
Currently, the middle-end is the old passthrough code, and it build hardware
vertices, not vertex_header vertices as above. It may be that passthrough
is a special case in this respect.
|
|
|
|
|
|
Should hopefully be OK now (on the fragprog size) for MRT. The hack from
a commit 01cb2cd93efe7ad94d7fd36aa5a776c2e3ab4c7d is no longer needed.
|
|
|
|
|
|
Temporary, the fp reg handling will get reworked at some point in the near
future. But before that, there's a few bugs to find.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Move these to a higher level instead.
|
|
|
|
|
|
Also fixup the constant emission
this breaks glxgears from what I can see but its another step to correctness
|
|
Code generation should be performed when the device-specific state
atom is created, not when it is bound.
|
|
Previously the constant color blend factor was compiled into the
generated code. This meant that the code had to be regenerated each
time the constant color was changed. This doesn't fit with the model
used in Gallium.
As-is, the code could be better. The constant color is loaded for
every quad processed, even if it is not used. Also, if a lot of (1-x)
blend factors are used, 1.0 will be loaded and reloaded into registers
many times.
|
|
|
|
I suspect that there was some other bug in the blend code-gen that
made this work-around necessary.
|
|
If only glUniform is called between two renderings, the const buffers weren't
getting updated. Need to set the _NEW_PROGRAM flag in st_upload_constants()
as that's the dirty flag set by glUniform.
Fixes glean tapi2 test.
|
|
The pass1 optimization stage clears out writemasks and registers, but the
instructions themselves are still being processed at this stage, and could
have resulted in them still being emitted.
|
|
|
|
|
