llvmpipe: calculate more accurate interpolation value at origin

Some rounding errors could crop up when calculating a0. Use a more accurate
method (barycentric interpolation essentially) to fix this, though to fix
the REAL problem (which is that our interpolation will give very bad results
with small triangles far away from the origin when they have steep gradients)
this does absolutely nothing (actually makes it worse). (To fix the real
problem, either would need to use a vertex corner (or some other point inside
the tri) as starting point value instead of fb origin and pass that down to
interpolation, or mimic what hw does, use barycentric interpolation (using
the coordinates extracted from the rasterizer edge functions) - maybe another
time.)
Some (silly) tests though really want a high accuracy at fb origin and don't
care much about anything else (Just. Don't. Ask.).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
i965: Convert brw->batch.is_blit to a BLT_RING/RENDER_RING enum.

Passing BLT_RING or RENDER_RING to batchbuffer functions is a lot more
obvious than passing true or false.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Introduce an UNKNOWN_RING state.

When we first create a batch buffer, it's empty.  We don't actually
know what ring it will be targeted at until the first BEGIN_BATCH or
BEGIN_BATCH_BLT macro.

Previously, one could determine the state of the batch by checking
brw->batch.ring (blit vs. render) and brw->batch.used != 0 (known vs.
unknown).

This should be functionally equivalent, but the tri-state enum is a bit
clearer.

v2: Catch three explicit require_space callers (thanks to Carl and Eric).
v3: Split the boolean -> enum change from the UNKNOWN_RING change.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Introduce a "render ring prelude" hook.

The new intel_batchbuffer_emit_render_ring_prelude() hook will be called
when switching from BLT or UNKNOWN_RING to RENDER_RING.  This provides a
place to emit state that should go at the start of each render ring
batch, with minimal overhead.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Move brw_emit_query_begin() to the render ring prelude.

Without hardware contexts, the pipeline statistics registers are
free-running and include data from every 3D application running.

In order to find out the contributions of one particular context, we
need to take a snapshot at the start and end of each batch.

Previously, we emitted the PIPE_CONTROL necessary to capture
PS_DEPTH_COUNT when drawing primitives.  Special tracking ensured it
happened only on the first draw of the batch, rather than on every draw.

Moving this to brw_new_batch increases symmetry, since the final
snapshot has always been in brw_finish_batch, which is just a few lines
below.  It should be basically equivalent.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Add INTEL_DEBUG=perfmon support.

This will enable debugging printfs for the AMD_performance_monitor code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Add basic driver hooks and plumbing for AMD_performance_monitor.

These stub functions will be filled out in later patches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Periodically dump the list of monitors if INTEL_DEBUG=perfmon.

It's useful to see the state of all outstanding monitors; the start
of a new batch seems like a reasonable time to print them out.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Add macros for creating performance monitor counters and groups.

The Observability Architecture counters are 32-bit unsigned values, and
the Pipeline Statistics Register counters are 64-bit unsigned values.

These convenience macros make it easy to create those types of counters.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Initialize performance monitor Groups/NumGroups.

Since we don't support any counters, there are zero groups.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Enumerate the pipeline statistics register counters on Gen6+.

For now, we only support these on Gen6+, since that's what currently
uses hardware contexts.  When we add Ironlake hardware context support,
we can add pipeline statistics register support for that as well.

In theory, we could support pipeline statistics counters even without
hardware contexts, but it would be annoyingly painful.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Expose pipeline statistics registers via performance monitors.

This is fairly simple:
- At BeginPerfMonitor time, take an opening snapshot.
- At EndPerfMonitor time, take a closing snapshot.
- The first time the application asks for results, subtract the two and
  store that value.  Then free the BO containing the snapshots.
- On subsequent requests for the results, just return the saved value.
- On reset, throw away the results.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Enumerate Observability Architecture counters on Gen5+.

In addition to listing the counter names, we include several "remap"
tables.  Confusingly, counters are documented with names like "A23",
are written to some buffer offset other than 23, and exposed by core
Mesa under a counter ID that is different still.

The first is inevitable; MI_REPORT_PERF_COUNT writes certain counters to
fixed locations in the buffer.  The latter could be avoided, but core
Mesa uses the "Counters" array index as the ID for a counter.  We could
do remapping there, but it would just complicate the core Mesa code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Track the number of monitors that need OA counters.

Using the OA counters requires some per-batch work.  When starting and
ending a batch, it's useful to know whether any monitors are actually
interested in OA data.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Add a function to emit the MI_REPORT_PERF_COUNT packet.

MI_REPORT_PERF_COUNT writes a snapshot of the Observability Architecture
counters to a buffer.  Exactly how it works varies between generations:
Ironlake requires two packets, Sandybridge has to use GGTT, and Ivybridge
and later use PPGTT.

v2: Assert that we didn't use more space than we reserved (suggested
    by Eric Anholt).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Take OA counter snapshots at Begin/EndPerfMonitor time.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Add #defines for the OACONTROL register and fields.

We'll need to write this register to start/stop performance counters.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Add functions to start and stop the OA counters.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Start and stop OA counters as necessary.

We need to start OA at the beginning of each batch where monitors are
active.  OACONTROL isn't part of the hardware context, so to avoid
leaving counters enabled for other applications, we turn them off at the
end of the batch too.

We also need to start them at BeginPerfMonitor time (unless they've
already been started).  We stop them when the monitor last ends as well.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Add some plumbing for gathering OA results.

Currently, this only considers the monitor start and end snapshots.
This is woefully insufficient, but allows me to add a bunch of the
infrastructure now and flesh it out later.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>