| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Just say no to:
- brw->tes.base.prog_data = &brw->tes.prog_data->base.base;
We'll just use the brw_stage_prog_data pointer in brw_stage_state
and downcast it to brw_tes_prog_data as needed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arcero@collabora.com>
|
| |
|
|
|
|
|
|
| |
This plugs the subroutine index updates into the i965 backend,
where it loads constants.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Andres Gomez <agomez@igalia.com>
|
| |
|
|
| |
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For several reasons, I don't think it's particularly useful to have
separate flags:
1. Most of the time, tessellation shaders are paired, so both will be
replaced at the same time.
2. The data layout is tightly coupled. Both need to agree on the number
of per-patch slots in the VUE map. Even adding extra TCS outputs
that aren't read by the TES will trigger the need for recompiles.
3. The TCS is optional from an API perspective, but required by the
hardware whenever tessellation is enabled. So, atoms that deal with
the TCS must check brw->tess_eval_program (BRW_NEW_TESS_EVAL_PROGRAM?)
rather than brw->tess_ctrl_program to tell whether tessellation is
enabled.
So, not only is it unlikely to be useful, it's a bit confusing to get
right. Simply using one flag for both simplifies this.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
|
This is brw_gs_surface_state.c copy and pasted twice with search and
replace.
brw_binding_table.c code is similarly copy and pasted.
v2: Drop dword_pitch related fields.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
|
