* [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
@ 2011-03-28 17:55 Eric Anholt
2011-03-28 22:22 ` Ian Romanick
2011-03-28 22:37 ` Ben Widawsky
0 siblings, 2 replies; 7+ messages in thread
From: Eric Anholt @ 2011-03-28 17:55 UTC (permalink / raw)
To: intel-gfx
---
Here's an idea for an SNB performance improvement from the specs. It
says that on GT2 you should be able to use 80 threads if "WIZ Hashing
Disable in GT_MODE register enabled". On my system (supposedly GT2),
that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write
0x20d0 0x00400040 (it only successfully took once, I suspect due to
FORCEWAKE, which also means that I can't necessarily trust that the
bit was unset originally), I got only hangs from 3D.
src/mesa/drivers/dri/i965/brw_context.c | 6 +++++-
src/mesa/drivers/dri/i965/gen6_wm_state.c | 2 +-
src/mesa/drivers/dri/intel/intel_chipset.h | 10 ++++++----
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c
index 9483ec6..3555e44 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -184,7 +184,11 @@ GLboolean brwCreateContext( int api,
if (intel->gen >= 6) {
brw->urb.size = 1024;
brw->vs_max_threads = 60;
- brw->wm_max_threads = 80;
+ if (IS_GT2(intel->intelScreen->deviceID)) {
+ brw->wm_max_threads = 80;
+ } else {
+ brw->wm_max_threads = 40;
+ }
} else if (intel->gen == 5) {
brw->urb.size = 1024;
brw->vs_max_threads = 72;
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index 78901ec..b91e1c1 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -144,7 +144,7 @@ upload_wm_state(struct brw_context *brw)
dw4 |= (brw->wm.prog_data->first_curbe_grf <<
GEN6_WM_DISPATCH_START_GRF_SHIFT_0);
- dw5 |= (40 - 1) << GEN6_WM_MAX_THREADS_SHIFT;
+ dw5 |= (brw->wm.max_threads - 1) << GEN6_WM_MAX_THREADS_SHIFT;
/* CACHE_NEW_WM_PROG */
if (brw->wm.prog_data->dispatch_width == 8)
diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h b/src/mesa/drivers/dri/intel/intel_chipset.h
index 4ff9140..f7dcf47 100644
--- a/src/mesa/drivers/dri/intel/intel_chipset.h
+++ b/src/mesa/drivers/dri/intel/intel_chipset.h
@@ -125,12 +125,14 @@
/* Compat macro for intel_decode.c */
#define IS_IRONLAKE(devid) IS_GEN5(devid)
-#define IS_GEN6(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
- devid == PCI_CHIP_SANDYBRIDGE_GT2 || \
+#define IS_GT2(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT2 || \
devid == PCI_CHIP_SANDYBRIDGE_GT2_PLUS || \
- devid == PCI_CHIP_SANDYBRIDGE_M_GT1 || \
devid == PCI_CHIP_SANDYBRIDGE_M_GT2 || \
- devid == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS || \
+ devid == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS)
+
+#define IS_GEN6(devid) (IS_GT2(devid) || \
+ devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
+ devid == PCI_CHIP_SANDYBRIDGE_M_GT1 || \
devid == PCI_CHIP_SANDYBRIDGE_S)
#define IS_GT1(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
--
1.7.4.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
2011-03-28 17:55 [PATCH] [WIP] i965: Use up to 80 WM threads on GT2 Eric Anholt
@ 2011-03-28 22:22 ` Ian Romanick
2011-03-29 0:32 ` Shuang He
2011-03-29 4:43 ` Eric Anholt
2011-03-28 22:37 ` Ben Widawsky
1 sibling, 2 replies; 7+ messages in thread
From: Ian Romanick @ 2011-03-28 22:22 UTC (permalink / raw)
To: Eric Anholt; +Cc: intel-gfx
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/28/2011 10:55 AM, Eric Anholt wrote:
> Here's an idea for an SNB performance improvement from the specs. It
> says that on GT2 you should be able to use 80 threads if "WIZ Hashing
> Disable in GT_MODE register enabled". On my system (supposedly GT2),
> that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write
> 0x20d0 0x00400040 (it only successfully took once, I suspect due to
> FORCEWAKE, which also means that I can't necessarily trust that the
> bit was unset originally), I got only hangs from 3D.
So, we're currently using too many threads in some cases? Could this be
related to bug #35730? In that case the failure seems to be limited to
SugarBay. I believe that's GT1, but I can never get the code names for
these chips straight.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2RCisACgkQX1gOwKyEAw8nRgCgnC1HMyfVwx5MLiaVF4mVzprQ
oD4An2DMFJdXfYKOyvehR7x6qAQnYix6
=4m/t
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
2011-03-28 22:22 ` Ian Romanick
@ 2011-03-29 0:32 ` Shuang He
2011-03-29 4:43 ` Eric Anholt
1 sibling, 0 replies; 7+ messages in thread
From: Shuang He @ 2011-03-29 0:32 UTC (permalink / raw)
To: Ian Romanick; +Cc: intel-gfx@lists.freedesktop.org
On 2011/3/29 6:22, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/28/2011 10:55 AM, Eric Anholt wrote:
>
>> Here's an idea for an SNB performance improvement from the specs. It
>> says that on GT2 you should be able to use 80 threads if "WIZ Hashing
>> Disable in GT_MODE register enabled". On my system (supposedly GT2),
>> that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write
>> 0x20d0 0x00400040 (it only successfully took once, I suspect due to
>> FORCEWAKE, which also means that I can't necessarily trust that the
>> bit was unset originally), I got only hangs from 3D.
> So, we're currently using too many threads in some cases? Could this be
> related to bug #35730? In that case the failure seems to be limited to
> SugarBay. I believe that's GT1, but I can never get the code names for
> these chips straight.
The system environment description section in bug #35730 already mention
it's rev09 GT1
Thanks
--Shuang
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2RCisACgkQX1gOwKyEAw8nRgCgnC1HMyfVwx5MLiaVF4mVzprQ
> oD4An2DMFJdXfYKOyvehR7x6qAQnYix6
> =4m/t
> -----END PGP SIGNATURE-----
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
2011-03-28 22:22 ` Ian Romanick
2011-03-29 0:32 ` Shuang He
@ 2011-03-29 4:43 ` Eric Anholt
2011-03-29 6:52 ` Chris Wilson
1 sibling, 1 reply; 7+ messages in thread
From: Eric Anholt @ 2011-03-29 4:43 UTC (permalink / raw)
To: Ian Romanick; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 1078 bytes --]
On Mon, 28 Mar 2011 15:22:35 -0700, Ian Romanick <idr@freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/28/2011 10:55 AM, Eric Anholt wrote:
>
> > Here's an idea for an SNB performance improvement from the specs. It
> > says that on GT2 you should be able to use 80 threads if "WIZ Hashing
> > Disable in GT_MODE register enabled". On my system (supposedly GT2),
> > that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write
> > 0x20d0 0x00400040 (it only successfully took once, I suspect due to
> > FORCEWAKE, which also means that I can't necessarily trust that the
> > bit was unset originally), I got only hangs from 3D.
>
> So, we're currently using too many threads in some cases? Could this be
> related to bug #35730? In that case the failure seems to be limited to
> SugarBay. I believe that's GT1, but I can never get the code names for
> these chips straight.
Nope, note how instead of using that original wm_max_threads value, 40
is hardcoded in the place that should have been using it.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
2011-03-29 4:43 ` Eric Anholt
@ 2011-03-29 6:52 ` Chris Wilson
0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2011-03-29 6:52 UTC (permalink / raw)
To: Eric Anholt, Ian Romanick; +Cc: intel-gfx
On Mon, 28 Mar 2011 21:43:28 -0700, Eric Anholt <eric@anholt.net> wrote:
> On Mon, 28 Mar 2011 15:22:35 -0700, Ian Romanick <idr@freedesktop.org> wrote:
> > So, we're currently using too many threads in some cases? Could this be
> > related to bug #35730? In that case the failure seems to be limited to
> > SugarBay. I believe that's GT1, but I can never get the code names for
> > these chips straight.
>
> Nope, note how instead of using that original wm_max_threads value, 40
> is hardcoded in the place that should have been using it.
But for DevSmallGT (which *is* GT1 right?) max VS threads is only 24.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
2011-03-28 17:55 [PATCH] [WIP] i965: Use up to 80 WM threads on GT2 Eric Anholt
2011-03-28 22:22 ` Ian Romanick
@ 2011-03-28 22:37 ` Ben Widawsky
2011-03-29 4:46 ` Eric Anholt
1 sibling, 1 reply; 7+ messages in thread
From: Ben Widawsky @ 2011-03-28 22:37 UTC (permalink / raw)
To: Eric Anholt; +Cc: intel-gfx
On Mon, Mar 28, 2011 at 10:55:40AM -0700, Eric Anholt wrote:
> ---
> I suspect due to
> FORCEWAKE, which also means that I can't necessarily trust that the
> bit was unset originally), I got only hangs from 3D.
If you want to get some more possibly garbage data, you can set
forcewake from userspace, and hope the kernel doesn't unset it :).
intel_reg_write 0xa18c 1
# check for ack
intel_reg_read 0x130090
I've never tried it, but it might work at least for reading that first
bit. I'm currenty working around this with <1301105269-23970-1-git-send-email-ben@bwidawsk.net>
and a hack in the kernel to do a get() and never do a put.
Ben
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
2011-03-28 22:37 ` Ben Widawsky
@ 2011-03-29 4:46 ` Eric Anholt
0 siblings, 0 replies; 7+ messages in thread
From: Eric Anholt @ 2011-03-29 4:46 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]
On Mon, 28 Mar 2011 15:37:37 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> On Mon, Mar 28, 2011 at 10:55:40AM -0700, Eric Anholt wrote:
> > ---
> > I suspect due to
> > FORCEWAKE, which also means that I can't necessarily trust that the
> > bit was unset originally), I got only hangs from 3D.
>
> If you want to get some more possibly garbage data, you can set
> forcewake from userspace, and hope the kernel doesn't unset it :).
>
> intel_reg_write 0xa18c 1
> # check for ack
> intel_reg_read 0x130090
>
> I've never tried it, but it might work at least for reading that first
> bit. I'm currenty working around this with <1301105269-23970-1-git-send-email-ben@bwidawsk.net>
> and a hack in the kernel to do a get() and never do a put.
I'm tempted by the idea of having a kernel interface for unpriveleged
interfaces for reading these regs, which would allow for non-root
gpu_top in addition to doing the forcewake. It'll suck to maintain a
list of unpriveleged-OK regs, though.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-03-29 6:52 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-28 17:55 [PATCH] [WIP] i965: Use up to 80 WM threads on GT2 Eric Anholt
2011-03-28 22:22 ` Ian Romanick
2011-03-29 0:32 ` Shuang He
2011-03-29 4:43 ` Eric Anholt
2011-03-29 6:52 ` Chris Wilson
2011-03-28 22:37 ` Ben Widawsky
2011-03-29 4:46 ` Eric Anholt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.