| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
The slightly less mechanical change of converting the emit_reloc calls
will follow.
|
| |
|
|
|
|
|
|
| |
This basically restores the previous state, where a vertex result slot
is set up for the texcoord to be replaced with point coord. Fixes
piglit point-sprite test.
Bug #27625
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The code was walking over the regs of pairs of attributes and checking
whether the attribute with a given reg index had point sprite enabled.
So the point sprite setup code was rarely even getting executed.
Instead, we need to determine which channels of a reg need point
sprite coordinate replacement. In addition, it was multiplying the
attribute by 1/w, when it's supposed to cover (0, 1) in each direction
regardless of w, and it wasn't filling in the Z and W components of
the texcoord as specified.
Fixes piglit point-sprite and the spriteblast demo. Bug #24431, #22245.
|
| |
|
|
|
|
| |
Everything has been constant-sized until now, but constant buffer
handling changes will make us want some additional variable sized
array.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
| |
|
|
|
| |
Shrinks size of key to 8 bytes from 12.
Note that progs/demos/spriteblast.c is still broken.
|
| |
|
|
|
|
|
| |
...rather than with linear interpolation. Modern hardware should use
perspective-corrected interpolation for colors (as for texcoords).
glHint(GL_PERSPECTIVE_CORRECTION_HINT, mode) can be used to get
linear interpolation if mode = GL_FASTEST.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the i965, the FBO coordinate system is inverted from the standard
OpenGL/Mesa coordinate system; that means that the viewport and the
polygon face orientation have to be inverted if rendering to a FBO.
The viewport was already being handled correctly; but polygon face
was not. This caused a conform failure when rendering to texture with
two-sided lighting enabled.
This fixes the problem in the i965 driver, and adds to the comment about
the gl_framebuffer "Name" field so that this isn't a surprise to other
driver writers.
|
| | |
|
| | |
|
| |
|
|
| |
Makefile.template
|
| |
|
|
| |
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
| |
|
|
|
|
|
|
| |
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
| |
|
|
|
|
| |
To do this, I had to clean up some of 965 state upload stuff. We may end
up over-emitting state in the aperture overflow case, but that should be rare,
and I'd rather have the simplification of state management.
|
| |
|
|
|
|
|
|
|
| |
Makes state emission into a 2 phase, prepare sets things up and accounts
the size of all referenced buffer objects. The emit stage then actually
does the batchbuffer touching for emitting the objects.
There is an assert in dri_emit_reloc if a reloc occurs for a buffer
that hasn't been accounted yet.
|
| |
|
|
| |
for WM payload. fix #10767
|
| | |
|
| |
|
|
| |
it ensures there are sufficient registers for all subroutines.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The user-space suballocator that was used avoided relocation computations by
using the general and surface state base registers and allocating those types
of buffers out of pools built on top of single buffer objects. It also
avoided calls into the buffer manager for these small state allocations, since
only one buffer object was being used.
However, the buffer allocation cost appears to be low, and with relocation
caching, computing relocations for buffers is essentially free. Additionally,
implementing the suballocator required a don't-fence-subdata flag to disable
waiting on buffer maps so that writing new data didn't block on rendering using
old data, and careful handling when mapping to update old data (which we need
to do for unavoidable relocations with FBOs). More importantly, when the
suballocator filled, it had no replacement algorithm and just threw out all
of the contents and forced them to be recomputed, which is a significant cost.
This is the first step, which just changes the buffer type, but doesn't yet
improve the hash table to not result in full recompute on overflow. Because
the buffers are all allocated out of the general buffer allocator, we can
no longer use the general/surface state bases to avoid relocations, and they
are set to 0 instead.
|
| |
|
|
|
|
|
|
|
| |
state."
I had forgotten part of brw_state_cache.c that made this fix not relevant for
master (last_addr comparison and flagging based on cache id).
This reverts commit a4642f3d18bdaebaba31e5dee72fe5de9d890ffb.
|
| |
|
|
|
|
| |
Otherwise, choosing a new program wouldn't necessarily update the state, and
and an old program could be executed, leading to various sorts of pretty
pictures or hangs.
|
| |
|
|
|
|
| |
and keep the instruction state unchanged after calling
brw_emit_tri_setup/brw_emit_line_setup when building setup
thread for SF_UNFILLED_TRIS.
|
| |
|
|
|
| |
compiling sf_prog. fix bug#11378 (which is introduced by
commit d619cceea47dc3070ebb7f7ea4f8b6b31a672d38)
|
| | |
|
|
|
This driver comes from Tungsten Graphics, with a few further modifications by
Intel.
|
