er was just a mirage after all.
> + const int ret = drmIoctl(psp->fd, DRM_IOCTL_I915_GETPARAM, &getparam);
> + intelScreen->has_resource_streamer = (ret != -1 || errno != EINVAL);
NO!!! You must always inspect the getparam.value. The trick is.
getparam.param = HAS_RESOURCE_S
_table,
> };
>
> +/**
> + * Hardware-generated binding tables for the resource streamer
> + */
> +void
> +gen7_disable_hw_binding_tables(struct brw_context *brw)
> +{
> + int pkt_len = brw->gen >= 8 ? 4 : 3;
How do you anticipate this function being used? As
urface-state base address. It would seem that separating the
surfaces into their own state bo would cut down on the amount of RS
traffic (you would not need to reload the binding table bo every batch,
nor change the entries as often). Right?
-Chris
--
Chri
On Fri, Jun 26, 2015 at 01:59:17PM +0300, Abdiel Janulgue wrote:
>
>
> On 06/26/2015 10:55 AM, Chris Wilson wrote:
> > On Fri, Jun 26, 2015 at 08:52:01AM +0300, Abdiel Janulgue wrote:
> >> When hardware-generated binding tables are enabled, use the hw-generated
> &
, write_domain);
> + int ret = drm_intel_bo_emit_reloc_48bit(brw->batch.bo, 4*brw->batch.used,
> + buffer, delta,
> + read_domains, write_domain);
I would have just exposed setting the flag on the
as being the relocation
address even if the top dword must be zero.
You can adopt the libdrm interface Ben suggested underneath the
macros, but having it marked as being both a 64-bit relocation and a w/a
in the source is pricless imo.
-Chris
--
C
+* issue a state cache invalidate."
> +*/
> + brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_INVALIDATE);
Should this flush not be before the enable? It's a top-of-pipe sync,
which means that the enable 3DSTATE will be parsed and changing the GPU
state
Since the last posting, it has grown a few superficial patches for
tweaks in the general area and a couple of drive-bys from looking at the
synmark profiles. As for the main patch, I've worked through the few
piglit regressions and it should be clean on ivb/byt/hsw/bdw to the best
of my knowledge,
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
index 283182d..7110ce6 100644
ralloc's ability to track all pointers belonging to a context and free
them in a single call does not come cheap, and we can reduce the
overhead here by combining the array of BITSETs for a regset into a
single allocation.
Signed-off-by: Chris Wilson
Cc: Matt Turner
Cc: Jason Ekstran
Since we can distinguish when mapping between READ and WRITE, we can
pass along the map mode to avoid stalls and flushes where possible.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 28 ++-
src/mesa/drivers/dri/i965/intel_mipmap_tree.h
the first context - and baring synchronisation issues should not
be a problem. Safer would be to move that also to the screen.)
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_pipe_control.c | 6 +++---
src/mesa/drivers/dri/i965/intel_screen.c | 4
src/mesa/drivers/dri
On LLC, all buffers are normally cache coherent between the CPU and the
GPU, giving both parties fast access to shared data.
However, older architectures or Atoms, do not implement LLC between the
CPU and GPU. Instead they utilise a snooping architecture where the GPU
can snoop the CPU cache when
No external users, so no need to export the symbol outside of our
compilation unit.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 36 +--
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 7 --
2 files changed, 18 insertions(+), 25
Since the purpose of transform feedback tends to be for the client to
act upon the results to change the geometry in the scene, it is likely
that the client will soon be waiting upon the results. Flush the batch
early so that we don't build up a long queue of commands afterwards that
could delay th
Avoid unrequired synchronization if the user requests to map an unused
range on active buffer, equivalent to BufferSubData.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 78 +---
1 file changed, 42 insertions(+), 36 deletions(-)
diff
Rather than allocating a fresh page every time we clear a buffer, keep
that page around between invocations by tracking the last used offset
and only allocating a fresh page when we wrap.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 17 ++---
1
ality.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.c | 11
src/mesa/drivers/dri/i965/brw_batch.h | 19 +++--
src/mesa/drivers/dri/i965/brw_cc.c | 2 +-
src/mesa/drivers/dri/i965/brw_clip_state.c | 2 +-
src
times and check the register is
incrementing.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_extensions.c | 6 +-
src/mesa/drivers/dri/i965/intel_screen.c | 15 +++
src/mesa/drivers/dri/i965/intel_screen.h | 2 ++
3 files changed, 18 insertions(+), 5
With the exception of gen8, the sole user of the workaround bo are for
emitting pipe controls. Move it out of the purview of the batchbuffer
and into the pipecontrol.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.c | 7 +
src/mesa/drivers/dri/i965
18351.5us to 4787.1us on my ivb
i7-3720QM (in context that 18ms represents about 50% of the time it takes
to start X, though why X instantiates an intel_screen at all remains a
mystery).
Signed-off-by: Chris Wilson
Cc: Matt Turner
Cc: Jason Ekstrand
Cc: Martin Peres gen <= 5 && reg
The vertices require a large chunk of memory, currently allocated during
context creation. However, this memory is not required until use so we
can defer the allocation until the first swrast_Wakeup().
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/swrast_setup/ss_context.c | 9
application for current linkage against all known versions
first.
Signed-off-by: Chris Wilson
---
src/loader/loader.c | 46 --
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 8452cd3
may exceed the coordinate limit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90734
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Ian Romanick
Cc: Anuj Phogat
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/intel_blit.c | 62
is suitable
for any general usage (e.g. vertex data, texture data) and so only on
LLC can we offer that extension.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.c| 36 +
src/mesa/drivers/dri/i965/brw_batch.h| 8 +
src/mesa
On Mon, Jul 06, 2015 at 03:10:48PM +0300, Martin Peres wrote:
> On 06/07/15 13:33, Chris Wilson wrote:
> >Move the query for the TIMESTAMP register from context init to the
> >screen, so that it is only queried once for all contexts.
> >
> >On 32bit systems, some o
On Mon, Jul 06, 2015 at 04:29:49PM +0300, Martin Peres wrote:
>
>
> On 06/07/15 13:33, Chris Wilson wrote:
> >Since the workaround bo is used strictly as a write-only buffer, we need
> >only allocate one per screen and use the same one from all contexts.
> >
&g
On Mon, Jul 06, 2015 at 04:19:36PM +0300, Martin Peres wrote:
>
>
> On 06/07/15 16:15, Martin Peres wrote:
> >On 06/07/15 16:13, Chris Wilson wrote:
> >>On Mon, Jul 06, 2015 at 03:10:48PM +0300, Martin Peres wrote:
> >>>On 06/07/15 13:33, Chris Wilson
uct brw_context *brw,
> > +uint32_t reg,
> > +struct brw_bo *bo,
> > +uint32_t read_domains, uint32_t write_domain,
> > +uint32_t offset)
> > +{
> > + load_sized_register_me
me very much. I guess I need to learn about
AX_GCC_FUNC_ATTRIBUTE!
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Jul 06, 2015 at 09:05:18PM -0700, Kristian Høgsberg wrote:
> On Mon, Jul 6, 2015 at 12:36 PM, Kenneth Graunke
> wrote:
> > On Monday, July 06, 2015 11:33:15 AM Chris Wilson wrote:
> >> Since the purpose of transform feedback tends to be for the client to
> &g
On Tue, Jul 07, 2015 at 01:14:53PM +0300, Abdiel Janulgue wrote:
> On 07/06/2015 01:33 PM, Chris Wilson wrote:
> > @@ -600,7 +593,10 @@ brw_emit_null_surface_state(struct brw_context *brw,
> > 1 << BRW_SURFACE_WRITEDISABLE_B_SHIFT
On Tue, Jul 07, 2015 at 10:12:20AM +0100, Chris Wilson wrote:
> On Mon, Jul 06, 2015 at 09:05:18PM -0700, Kristian Høgsberg wrote:
> > On Mon, Jul 6, 2015 at 12:36 PM, Kenneth Graunke
> > wrote:
> > > On Monday, July 06, 2015 11:33:15 AM Chris Wilson wrote:
> > >
On Tue, Jul 07, 2015 at 10:31:07AM -0700, Kenneth Graunke wrote:
> On Tuesday, July 07, 2015 04:46:22 PM Chris Wilson wrote:
> > On Tue, Jul 07, 2015 at 10:12:20AM +0100, Chris Wilson wrote:
> > > On Mon, Jul 06, 2015 at 09:05:18PM -0700, Kristian Høgsberg wrote:
> > >
uction quality driver.
>
> Please advise whether you would like to work towards making a mergeable,
> incremental patch series, or if someone else should embark on that
> endeavour.
I'm happy to keep reworking the noise outside of brw-batch down to
acceptable levels, but a bit more resistant to rewritting the
brw_request tracking itself though.
Please do keep on making suggestions for dubious code and what to cut.
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Jul 07, 2015 at 01:42:47PM +0300, Martin Peres wrote:
> On 06/07/15 19:43, Kenneth Graunke wrote:
> >On Monday, July 06, 2015 11:33:10 AM Chris Wilson wrote:
> >>Rather than allocating a fresh page every time we clear a buffer, keep
> >>that page around between
On Mon, Jul 06, 2015 at 10:01:21AM -0700, Kenneth Graunke wrote:
> On Monday, July 06, 2015 05:12:10 PM Chris Wilson wrote:
> > On Mon, Jul 06, 2015 at 04:19:36PM +0300, Martin Peres wrote:
> > >
> > >
> > > On 06/07/15 16:15, Martin Peres wrote:
> >
On Mon, Jul 06, 2015 at 09:34:10AM -0700, Kenneth Graunke wrote:
> On Monday, July 06, 2015 11:33:08 AM Chris Wilson wrote:
> > Since the workaround bo is used strictly as a write-only buffer, we need
> > only allocate one per screen and use the same one from all contexts.
>
On Tue, Jul 07, 2015 at 08:40:12PM +0100, Emil Velikov wrote:
> On 06/07/15 11:33, Chris Wilson wrote:
> > Since there was an ABI break and linking twice against libudev.so.0 and
> > libudev.so.1 causes the application to quickly crash, we first check if
> > the applicatio
On Mon, Jul 06, 2015 at 09:30:48AM -0700, Kenneth Graunke wrote:
> On Monday, July 06, 2015 11:33:07 AM Chris Wilson wrote:
> > With the exception of gen8, the sole user of the workaround bo are for
> > emitting pipe controls. Move it out of the purview of the batchbuffer
&
Moving the test to the screen places it alongside the other global HW
feature tesst that want to be shared between contexts.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/drivers/dri/i965/intel_extensions.c | 69
the first context - and baring synchronisation issues should not
be a problem. Safer would be to move that also to the screen.)
v2: Give the workaround bo its own init function and don't piggy back
intel_bufmgr_init() since it is not that related.
Signed-off-by: Chris Wilson
Cc: Kenneth Gr
sters without a full batch flush.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/gen7_sol_state.c | 12 +++-
src/mesa/drivers/dri/i965/intel_extensions.c | 3 ++-
3 files changed, 14 insertions(
Combining the multiple access checks into a few batches and a single
serialising read can reduce detection times from around 100us to 70us on
a fast Haswell system.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_screen.c | 177
Similarly to the pipelined SO_OFFSET check, this moves the global HW
compatability check to the screen next to the other global checks.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.c | 1 +
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri
On Wed, Jul 08, 2015 at 09:51:07AM +0100, Chris Wilson wrote:
> On Tue, Jul 07, 2015 at 10:03:09PM -0700, Kenneth Graunke wrote:
> > * Gen4-5 structure changes.
Did you mean brw_structs.h?
diff --git a/src/mesa/drivers/dri/i965/brw_structs.h
b/src/mesa/drivers/dri/i965/brw_struct
On Wed, Jul 08, 2015 at 10:49:24AM -0700, Kenneth Graunke wrote:
> On Wednesday, July 08, 2015 03:17:35 PM Chris Wilson wrote:
> > On Wed, Jul 08, 2015 at 09:51:07AM +0100, Chris Wilson wrote:
> > > On Tue, Jul 07, 2015 at 10:03:09PM -0700, Kenneth Graunke wrote:
> > > &
code with multiple
adjacent emit_dwords. I have seen similar regressions when doing the
same batch[index] to *batch++ elsewhere.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jul 08, 2015 at 03:33:17PM -0700, Matt Turner wrote:
> On Wed, Jul 8, 2015 at 2:07 PM, Chris Wilson wrote:
> > On Wed, Jul 08, 2015 at 02:00:02PM -0700, Matt Turner wrote:
> >> By keeping a pointer to the next available location, we reduce the
> >> number o
On Thu, Jul 09, 2015 at 12:53:23AM +0100, Chris Wilson wrote:
> This is what I expected to see
>0x025e <+62>: movl $0x780d1c02,(%rcx)
>0x0264 <+68>: mov0x22f08(%rdi),%rax
>0x026b <+75>: mov0x24320(%rdi),%ed
On Wed, Jul 08, 2015 at 05:08:11PM -0700, Matt Turner wrote:
> On Wed, Jul 8, 2015 at 4:53 PM, Chris Wilson wrote:
> > static void upload_viewport_state_pointers(struct brw_context *brw)
> > {
> >BEGIN_BATCH(4);
> >brw->batch.map[0] = (_3DSTATE_VIEWPORT
OUT_BATCH(step_rate);
+
+ return out;
}
For the idx version, you can just pass idx in/out ofc.
Then you also don't have to track __final_idx for non-debug builds as the
check is just assert(__map == brw->batch.map);
The only catch is changing OUT_RELOC to use __map - brw->batch.base, b
rn it from the function instead.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Jul 10, 2015 at 11:44:58AM -0700, Matt Turner wrote:
> So that everything writing to the batch between BEGIN_BATCH() and
> ADVANCE_BATCH() goes through OUT_BATCH.
Reviewed-by: Chris Wilson
> +#define OUT_RELOC64(buf, read_domains, write_domain, delta) do {\
>
ed); \
> - } while (0)
> + SET_BLITTER_TILING(brw, dst_y_tiled, src_y_tiled)
using braces around the if () inside this macro, but
if ()
BEGIN_BATCH_TILED
else
something();
won't compile anyway.
For the series then,
Reviewed-by: Chris Wilson
It's worth Martin to
On Wed, Jul 15, 2015 at 12:20:15PM -0700, Kristian Høgsberg wrote:
> On Wed, Jul 15, 2015 at 10:22 AM, Kenneth Graunke
> wrote:
> > From: Chris Wilson
> >
> > The kernel actually waits forever when supplied a timeout value < 0,
> > rather than returning imme
On Fri, Jul 17, 2015 at 05:12:54PM -0700, Anuj Phogat wrote:
> On Mon, Jul 6, 2015 at 3:33 AM, Chris Wilson wrote:
> > + do {
> > + /* The pitch given to the GPU must be DWORD aligned, and
> > + * we want width to match pitch. Max width is (1 << 15 - 1),
be 32bit that had the shifted results. On the basis of
those mistakes, I wrote
commit c8d3ebaffc0d7d915c1c19d54dba61fd1e57b338
Author: Chris Wilson
Date: Wed Apr 29 13:32:38 2015 +0100
i965: Query whether we have kernel support for the TIMESTAMP register once
Now that we do have an extended
sysfs scan for PCI
devices.)
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Kristian Høgsberg
Cc: Kenneth Graunke
Cc: Ian Romanick
---
src/mesa/drivers/dri/i965/intel_screen.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri
ither never to throttle, throttle after every draw call,
or at an intermediate user defined point such as glFlush and thus all the
implied flushes. This patch opts for the latter.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Ben Widawsky
Cc: Kristian Høgsberg
---
src
On Wed, Mar 04, 2015 at 09:41:56AM -0800, Chad Versace wrote:
> On 02/26/2015 05:24 AM, Chris Wilson wrote:
> > When rendering to an fbo, even though it may be acting as a winsys
> > frontbuffer or just generally, we never throttle. However, when rendering
> > to an fbo, ther
On Wed, Mar 04, 2015 at 10:28:16AM -0800, Chad Versace wrote:
> On 03/04/2015 09:52 AM, Chris Wilson wrote:
> > The manpage for glFlush says
> >
> > "glFlush can return at any time. It does not wait until the execution of
> > *all*
> > pre
continue at your own peril.
Will you please fix your code then.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
next
intel_prepare_render() and switch non-fbo frontbuffer throttling over to
use the same lax method. The issuing being that
glFlush()/intel_prepare_read() is just as likely to be called inside a
tight loop and not at "frame" boundaries.
Signed-off-by: Chris Wilson
Cc: Daniel Vett
next
intel_prepare_render() and switch non-fbo frontbuffer throttling over to
use the same lax method. The issuing being that
glFlush()/intel_prepare_read() is just as likely to be called inside a
tight loop and not at "frame" boundaries.
Signed-off-by: Chris Wilson
Cc: Daniel Vett
improving throughput and reducing jitter.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Ben Widawsky
Cc: Kristian Høgsberg
Cc: Chad Versace first_post_swapbuffers_batch);
- brw->first_post_swapbuffers_batch = NULL;
+ drm_intel_bo_unreference(
"first_post_swapbuffer" batches array to a plain
throttle_batch[] as the pluralisation was contorting the name and not
making it clear as to whether it was the first batch or first_post_swap
batch. Not least of which was that not all throttle points are SwapBuffers.
Signed-off-by: Chris Wilson
ush_throttle to avoid any
ambiguity between front buffer rendering and fbo rendering. (Chad)
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Ben Widawsky
Cc: Kristian Høgsberg
Cc: Chad Versace
Reviewed-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_
mings of the previous
scheme, since often it is the same render target being used over and over
again..
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
ve there's nothing technically blocking it from landing, but Chad
> > wanted to push them only after the kernel patches had landed.
>
> Right. I'm waiting for the kernel devs to agree to Chris's execbuffer
> fence fd patch.
>
> > Hi Chris, do we
&device->alloc);
> + break;
> + default:
> + break;
> + }
> + }
Seperate in/out arrays curtains the issues I could see with the implicit
fences accidentally serialising input-only semaphores.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
ct anv_semaphore_impl *impl = &semaphore->permanent;
> +
> + if (impl->type == ANV_SEMAPHORE_TYPE_SYNC_FILE) {
> +assert(impl->fd == -1);
> +impl->fd = dup(out_fence);
out_fence will still be zero/stdin if anv_device_execbuf() failed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
maintained and the custom interface
for Intel is where our overhead lies. And yes, we are the only ones
using this interface.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://li
used illegal commands. Fix the array
initialisation to be impervious to changes in the gl_shader_stages enum
and add the asserts that would have caught the issue earlier.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
Cc: Jordan Justen
Cc: Matt Turner
Cc: Kenneth Graunke
---
src/mesa
so
6491766 191992 26192 6709950 6662be lib64/i965_dri.so
Small inflation due to the extra immediate masks and entirely dubious as
to whether it is worth it.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.h | 76 +++--
src/mesa/driver
Just a couple of functions for removing an element from one list and
adding to another (perhaps even the same list, just at the head or
tail).
Used in future patches.
Signed-off-by: Chris Wilson
---
src/util/list.h | 27 +--
1 file changed, 21 insertions(+), 6 deletions
A new round for brw_batch.c now with lots and lots of baby steps
painstakingly individually tested.
Please tear to shreds.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
To ease future transitions.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 31 +++
src/mesa/drivers/dri/i965/brw_context.h | 31 ---
2 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/src/mesa
In order to reduce future churn, rename the intel_batchbuffer struct.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 4 ++--
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/brw_state_batch.c | 6 ++
src/mesa/drivers/dri/i965
In preparation for a local batch manager with a new buffer object, first
reduce the churn by renaming the existing buffer objects:
s/drm_intel_bo/brw_bo/
We only have to be careful to leave the global screen drm_intel_bo as
they are.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965
Moving the test to the screen places it alongside the other global HW
feature tesst that want to be shared between contexts.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 2 +
src/mesa/drivers/dri/i965/intel_extensions.c | 69
going astray, to a stale buffer, and not shown on the
screen, but it allows us to issue a warning and not crash much later in
innocent code.)
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_context.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965
Combining the multiple access checks into a few batches and a single
serialising read can reduce detection times from around 100us to 70us on
a fast Haswell system.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_screen.c | 165
To further reduce churn when replacing the buffer object implementation,
wrap the existing drm_intel_bo_reference/drm_intel_bo_unreference.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 12 +++
src/mesa/drivers/dri/i965/brw_context.c
Similarly to the pipelined SO_OFFSET check, this moves the global HW
compatability check to the screen next to the other global checks.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_extensions.c | 68 +---
src/mesa/drivers/dri/i965/intel_screen.c
the first context - and baring synchronisation issues should not
be a problem. Safer would be to move that also to the screen.)
v2: Give the workaround bo its own init function and don't piggy back
intel_bufmgr_init() since it is not that related.
Signed-off-by: Chris Wilson
Cc: Kenneth Gr
Upcoming patches eliminate the intel_batchbuffer interface and one of
the minor changes that causes a lot of churn is the removal of the
header, along with the occassional need to now call intel_reg.h
themselves. This patch moves the individual includes into brw_context.h.
Signed-off-by: Chris
sters without a full batch flush.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/gen7_sol_state.c | 13 -
src/mesa/drivers/dri/i965/intel_extensions.c | 3 ++-
3 files changed, 15 insertions(
To reduce later churn, extract drm_intel_bo_madvise() with a smaller
wrapper.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 5 +
src/mesa/drivers/dri/i965/brw_object_purgeable.c | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src
Just to reduce some later churn, pull out the flink wrapper.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h| 7 +++
src/mesa/drivers/dri/i965/brw_context.c | 11 +--
src/mesa/drivers/dri/i965/intel_screen.c | 6 ++
3 files changed, 14 insertions
To reduce churn later, move the brw->render_cache dirty set into the
batch (i.e. brw->batch.render_cache).
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 7 +++
src/mesa/drivers/dri/i965/brw_context.h | 7 ---
src/mesa/drivers/dri/i965/intel_fbo.c
Move the pipelined register access out of intel_batchbuffer into its
own utility file in preparation for replacing intel_batchbuffer. This
also gives us the opportunity to refactor a few similar routines for
writing registers, and so should prove useful in its own right.
Signed-off-by: Chris
gen7_sol_state loads the SOL_OFFSET registers from its scratch buffer
by hand, switch it over to the common routine for emitting that command.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
A simple helper to check whether the last batch buffer submitted to the
hardware is still busy. Extract it now to reduce churn later.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 5 +
src/mesa/drivers/dri/i965/brw_cs.cpp | 5 ++---
src/mesa/drivers/dri/i965
Move the computation of the state offset into a smaller helper to reduce
churn later.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_state_dump.c | 62 --
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/src/mesa/drivers/dri/i965
-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_binding_tables.c | 3 ++-
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 15 +++
src/mesa/drivers/dri/i965/brw_program.c | 2 +-
src/mesa/drivers/dri/i965/brw_queryobj.c| 9 ++---
src/mesa
We have a few instances where we set a register to an immediate value
(MI_LOAD_REGISTER_IMM), so let's replace them with a simple routine.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_draw.c| 6 +-
src/mesa/drivers/dri/i965/brw_performance_monitor.c
Churn now to reduce churn later.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 34 +++
src/mesa/drivers/dri/i965/brw_binding_tables.c | 3 +-
src/mesa/drivers/dri/i965/brw_context.c| 3 +-
.../drivers/dri/i965
Since brw_batch will become the dominate interface for brw_bo, move the
pointer now to reduce later churn.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 2 ++
src/mesa/drivers/dri/i965/brw_binding_tables.c | 2 +-
src/mesa/drivers/dri/i965
To reduce churn later, move the HW context variable from brw_context to
brw_batch.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/brw_batch.h | 2 ++
src/mesa/drivers/dri/i965/brw_context.c | 22 +++---
src/mesa/drivers/dri/i965/brw_context.h | 2
1 - 100 of 1057 matches
Mail list logo
