| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
min/mag filter selection
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Avoids bo code bailing out because of mapped buffers being validated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's possible for the unsignalled list head to change during fence_flush.
Fixes valgrind complaint exposed by a previous commit.
|
|
Rather than spinning waiting for the GPU to finish with the buffer,
add a callback on the buffer's fence object instead. Gives a sizable
performance increase in OA.
|
|
Fixes some cases where we end up with a list of many unused chunks that are
too small to be useful.
|
|
|
|
|
|
- Alpha factor set to a _COLOR mode was mishandled
- Cases when either dst factor or src factor was ZERO were mishandled
- MIN and MAX cases were backwards
- Case when blend was disabled was mishandled
- Incorrect comments about number of instructions generated
The tests blendminmax and blendsquare run correctly.
|
|
Cut-and-paste for the lose. :(
|
|
|
|
So far this is only tested when GL_BLEND is disabled.
|
|
|
|
|
