| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Conflicts:
src/mesa/main/api_validate.c
|
|
For the TXP instruction we check if the texcoord is really a 4-component
atttibute which requires the divide by W step. This check involved the
projtex_mask field. However, the projtex_mask field was being miscalculated
because of some confusion between vertex program outputs and fragment
program inputs.
1. Rework the size_masks calculation so we correctly set bits corresponding
to fragment program input attributes.
2. Rename projtex_mask to proj_attrib_mask since we're interested in more
than just texcoords (generic varying vars too).
3. Simply the indexing of the size_masks and proj_attrib_mask fields.
4. The tracker::active[] array was mis-dimensioned. Use MAX_PROGRAM_TEMPS
instead of a magic number.
5. Update comments, add new assertions.
With these changes the Lightsmark demo/benchmark renders correctly, until
we eventually hit a GPU lockup...
|
|
This can avoid re-uploading constant data when it isn't necessary, and is
a step towards not updating other surfaces just because constants change.
It also brings the upload of the constant buffer next to the creation.
This brings openarena performance up another 4%, to 91% of the Mesa 7.4 branch.
|
|
Make the use_const_buffer field per-program and only call the code which
updates the constant buffer's data if the flag is set.
This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
(cherry picked from master, commit dc9705d12d162ba6d087eb762e315de9f97bc456)
|
|
Make the use_const_buffer field per-program and only call the code which
updates the constant buffer's data if the flag is set.
This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
|
|
|
|
The new, second cache will only be used for surface-related items.
Since we can create many surfaces the original, single cache could get
filled quickly. When we cleared it, we had to regenerate shaders, etc.
With two caches, we can avoid doing that.
|
|
No more dynamic atoms so we can simplify the state validation code a little.
|
|
Now that we have real constant buffers, the demands on the CURBE are lessened.
When we use real VS/WM constant buffers we only use the CURBE for clip planes.
|
|
Hook up a constant buffer, binding table, etc for the VS unit.
This will allow using large constant buffers with vertex shaders.
The new code is disabled at this time (use_const_buffer=FALSE).
|
|
Plus, begin the new code for vertex shader const buffers.
|
|
Used to map drawables, textures and constant buffers to surface binding
table indexes.
|
|
Currently, shader constants are stored in the GRF (loaded from the CURBE
prior to shader execution). This severly limits the number of constants
and temps that we can support.
This new code will support (practically) unlimited size constant buffers
and free up registers in the GRF. We allocate a new buffer object for the
constants and read them with "Read" messages/instructions. When only a
small number of constants are used, we can still use the old method.
The code works for fragment shaders only (and is actually disabled) for now.
Need to do the same thing for vertex shaders and need to add the necessary
code-gen to fetch the constants which are referenced by the shader
instructions.
|
|
|
|
|
|
|
|
This function scans the shader to see if it has any GLSL features like
conditionals and loops. Calling this during state validation is expensive.
Just call it when the shader is given to the driver and save the result.
There's some new/temporary assertions to be sure we don't get out of sync
on this.
|
|
|
|
Be a little more specific about what these are.
|
|
|
|
|
|
|
|
|
|
This lets GLSL shaders use up to 16 samplers.
Fixed function is still limited to 8 textures.
Tested with progs/glsl/samplers.c
|
|
This is fallout from the ffvertex_prog.c work. It doesn't call
ProgramStringNotify, so we don't set param_state, so we wouldn't track when
VP parameters changed, and constants wouldn't get uploaded. Instead, remove
param_state entirely and just use the real value that we want to be tracking.
Fixes rendering in openarena since BRW_NEW_BATCH got disentangled from
BRW_NEW_INDICES.
Bug #18822.
|
|
The CACHE_NEW_SURFACE bit always gets spammed since we get many different
surface BOs per state emit, but the only consumer of it wanted to just know
how many surfaces were enabled.
|
|
Fixes upload of large amounts of state for every new primitive emit.
|
|
This was causing a prepare of wm state at every primitive emit.
|
|
Previously, since my check_aperture API change, we would check each piece of
state against the batchbuffer individually, but not all the state against the
batchbuffer at once. In addition to not being terribly useful in assuring
success, it probably also increased CPU load by calling check_aperture many
times per primitive.
|
|
|
|
|
|
The i965 driver previously had it's own set of code to convert
fixed-function TNL state to a vertex program. Core Mesa has code to
do this, so there is no reason to duplicate that effort in the driver.
In fact, this duplication leads to bugs when other aspects of the Mesa
infrastructure change.
|
|
This isn't required for GEM (at least, yet), but the check_aperture code
for non-GEM results in batch getting flushed during emit. brw_state_upload
restarts state emits, but a bunch of the state emit functions were assuming
that they would be called exactly once, after prepare and before new_batch.
Bug #17179.
|
|
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.
|
|
|
|
|
|
With DRI2 we there is no screen region until a drawable is bound to
the context. Set up the framebuffer texture in meta_draw_region instead
which should also handle the case where the draw region changes as a
result of resizing a redirected window or resizing the screen.
|
|
for WM payload. fix #10767
|
|
This helps us avoid a bunch of mess with gl_client_arrays that we filled
with unused data and confused readers.
|
|
|
|
|
|
Since each one is only 64b, and kernel allocations are a page anyway, this
lets us reduce buffer allocation by packing many CURBEs into one buffer, for
each batchbuffer submitted. Improves openarena performance by around 10%.
|
|
The previous change gave us only two modes, one which looped over the batch
per cliprect (3d drawing) and one that didn't (state updeast).
However, we really want 4:
- Batch doesn't care about cliprects (state updates)
- Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing)
- Batch needs to be executed just once (region fills, copies, etc.)
- Batch already includes cliprect handling, and must be flushed by unlock time
(copybuffers, clears).
All callers should now be fixed to use one of these states for any batchbuffer
emits. Thanks to Keith Whitwell for pointing out the failure.
|
