*/
static void calculate_curbe_offsets( struct brw_context *brw )
{
- struct gl_context *ctx = &brw->intel.ctx;
+ struct gl_context *ctx = &brw->ctx;
/* CACHE_NEW_WM_PROG */
const GLuint nr_fp_regs = (brw->wm.prog_data->nr_params + 15) / 16;
/* BRW_NEW_VERTEX_PROGRAM */
- const GLuint nr_vp_regs = (brw->vs.prog_data->nr_params + 15) / 16;
+ const GLuint nr_vp_regs = (brw->vs.prog_data->base.nr_params + 15) / 16;
GLuint nr_clip_regs = 0;
GLuint total_regs;
.brw = BRW_NEW_VERTEX_PROGRAM | BRW_NEW_CONTEXT,
.cache = CACHE_NEW_WM_PROG
},
- .prepare = calculate_curbe_offsets
+ .emit = calculate_curbe_offsets
};
*/
void brw_upload_cs_urb_state(struct brw_context *brw)
{
- struct intel_context *intel = &brw->intel;
-
BEGIN_BATCH(2);
/* It appears that this is the state packet for the CS unit, ie. the
* urb entries detailed here are housed in the CS range from the
* cache mechanism, but maybe would benefit from a comparison against
* the current uploaded set of constants.
*/
-static void prepare_constant_buffer(struct brw_context *brw)
+static void
+brw_upload_constant_buffer(struct brw_context *brw)
{
- struct gl_context *ctx = &brw->intel.ctx;
- const struct brw_vertex_program *vp =
- brw_vertex_program_const(brw->vertex_program);
+ struct gl_context *ctx = &brw->ctx;
const GLuint sz = brw->curbe.total_size;
const GLuint bufsz = sz * 16 * sizeof(GLfloat);
GLfloat *buf;
if (sz == 0) {
brw->curbe.last_bufsz = 0;
- return;
+ goto emit;
}
buf = brw->curbe.next_buf;
/* copy float constants */
for (i = 0; i < brw->wm.prog_data->nr_params; i++) {
- buf[offset + i] = convert_param(brw->wm.prog_data->param_convert[i],
- brw->wm.prog_data->param[i]);
+ buf[offset + i] = *brw->wm.prog_data->param[i];
}
}
-
- /* When using the old VS backend, the clipplanes are actually delivered to
- * both CLIP and VS units. VS uses them to calculate the outcode bitmasks.
- *
- * When using the new VS backend, it is responsible for setting up its own
- * clipplane constants if it needs them. This results in a slight waste of
- * of curbe space, but the advantage is that the new VS backend can use its
- * general-purpose uniform layout code to store the clipplanes.
- */
+ /* clipper constants */
if (brw->curbe.clip_size) {
GLuint offset = brw->curbe.clip_start * 16;
GLuint j;
/* vertex shader constants */
if (brw->curbe.vs_size) {
GLuint offset = brw->curbe.vs_start * 16;
- GLuint nr = brw->vs.prog_data->nr_params / 4;
- if (brw->vs.prog_data->uses_new_param_layout) {
- for (i = 0; i < brw->vs.prog_data->nr_params; i++) {
- buf[offset + i] = *brw->vs.prog_data->param[i];
- }
- } else {
- /* Load the subset of push constants that will get used when
- * we also have a pull constant buffer.
- */
- for (i = 0; i < vp->program.Base.Parameters->NumParameters; i++) {
- if (brw->vs.constant_map[i] != -1) {
- assert(brw->vs.constant_map[i] <= nr);
- memcpy(buf + offset + brw->vs.constant_map[i] * 4,
- vp->program.Base.Parameters->ParameterValues[i],
- 4 * sizeof(float));
- }
- }
+ for (i = 0; i < brw->vs.prog_data->base.nr_params; i++) {
+ buf[offset + i] = *brw->vs.prog_data->base.param[i];
}
}
/* Allocate a single page for CURBE entries for this batchbuffer.
* They're generally around 64b.
*/
- brw->curbe.curbe_bo = drm_intel_bo_alloc(brw->intel.bufmgr, "CURBE",
+ brw->curbe.curbe_bo = drm_intel_bo_alloc(brw->bufmgr, "CURBE",
4096, 1 << 6);
brw->curbe.curbe_next_offset = 0;
drm_intel_gem_bo_map_gtt(brw->curbe.curbe_bo);
* flushes as necessary when doublebuffering of CURBEs isn't
* possible.
*/
-}
-
-static void emit_constant_buffer(struct brw_context *brw)
-{
- struct intel_context *intel = &brw->intel;
- GLuint sz = brw->curbe.total_size;
+emit:
BEGIN_BATCH(2);
- if (sz == 0) {
+ if (brw->curbe.total_size == 0) {
OUT_BATCH((CMD_CONST_BUFFER << 16) | (2 - 2));
OUT_BATCH(0);
} else {
OUT_BATCH((CMD_CONST_BUFFER << 16) | (1 << 8) | (2 - 2));
OUT_RELOC(brw->curbe.curbe_bo,
I915_GEM_DOMAIN_INSTRUCTION, 0,
- (sz - 1) + brw->curbe.curbe_offset);
+ (brw->curbe.total_size - 1) + brw->curbe.curbe_offset);
}
ADVANCE_BATCH();
}
-/* This tracked state is unique in that the state it monitors varies
- * dynamically depending on the parameters tracked by the fragment and
- * vertex programs. This is the template used as a starting point,
- * each context will maintain a copy of this internally and update as
- * required.
- */
const struct brw_tracked_state brw_constant_buffer = {
.dirty = {
.mesa = _NEW_PROGRAM_CONSTANTS,
BRW_NEW_BATCH),
.cache = (CACHE_NEW_WM_PROG)
},
- .prepare = prepare_constant_buffer,
- .emit = emit_constant_buffer,
+ .emit = brw_upload_constant_buffer,
};