* Valleyview: 3DSTATE_URB_VS Minimum URB Entries
@ 2012-07-03 4:07 Cheah, Douglas
2012-07-03 19:27 ` Jesse Barnes
0 siblings, 1 reply; 3+ messages in thread
From: Cheah, Douglas @ 2012-07-03 4:07 UTC (permalink / raw)
To: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 1781 bytes --]
Hello folks,
I am seeing corruption when running spectex from mesa demos which looks like vertex being randomly clipped on Valleyview, however spectex works fine on Ivy Bridge.
After tracing down the codes I realize that the current Mesa driver would program the maximum number or URB entries (512 Valleyview) whenever possible. This conflict with the 3D pipeline PRM where it states there is a programming restriction if the URB Entry Allocation Size is less than 9 URB entries then total entries should be program to 32. After modifying the codes to meet the restriction I was able to run spectex without corruption on Valleyview, pretty surprise that Ivy Bridge did not have this problem.
Here is the code snippet that I have changed which is at this point a quick hack and not upstream worthy as you can see the macro is not even properly defined in brw_defeines.h. Appreciate if I could get opinions from folks who are more familiar with Mesa and more experience with the graphic core.
static void
gen7_upload_urb(struct brw_context *brw)
{
struct intel_context *intel = &brw->intel;
/* Total space for entries is URB size - 16kB for push constants */
int handle_region_size = (brw->urb.size - 16) * 1024; /* bytes */
/* CACHE_NEW_VS_PROG */
brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1);
int nr_vs_entries = handle_region_size / (brw->urb.vs_size * 64);
if (nr_vs_entries > brw->urb.max_vs_entries)
nr_vs_entries = brw->urb.max_vs_entries;
/* If the number of URB Allocation Size is smaller than 9 512 bit
* units set the number or URB to Entries to 32
*/
#define GEN7_URB_VS_MIN_ENTRIES 32
if(brw->urb.vs_size < 9)
nr_vs_entries = GEN7_URB_VS_MIN_ENTRIES;
Douglas
[-- Attachment #1.2: Type: text/html, Size: 7854 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] 3+ messages in thread
* Re: Valleyview: 3DSTATE_URB_VS Minimum URB Entries
2012-07-03 4:07 Valleyview: 3DSTATE_URB_VS Minimum URB Entries Cheah, Douglas
@ 2012-07-03 19:27 ` Jesse Barnes
2012-07-04 5:50 ` Cheah, Douglas
0 siblings, 1 reply; 3+ messages in thread
From: Jesse Barnes @ 2012-07-03 19:27 UTC (permalink / raw)
To: Cheah, Douglas, intel-gfx
"Cheah, Douglas" <douglas.cheah@intel.com> wrote:
>Hello folks,
>
>I am seeing corruption when running spectex from mesa demos which looks
>like vertex being randomly clipped on Valleyview, however spectex works
>fine on Ivy Bridge.
>
>After tracing down the codes I realize that the current Mesa driver
>would program the maximum number or URB entries (512 Valleyview)
>whenever possible. This conflict with the 3D pipeline PRM where it
>states there is a programming restriction if the URB Entry Allocation
>Size is less than 9 URB entries then total entries should be program to
>32. After modifying the codes to meet the restriction I was able to run
>spectex without corruption on Valleyview, pretty surprise that Ivy
>Bridge did not have this problem.
>
>Here is the code snippet that I have changed which is at this point a
>quick hack and not upstream worthy as you can see the macro is not even
>properly defined in brw_defeines.h. Appreciate if I could get opinions
>from folks who are more familiar with Mesa and more experience with the
>graphic core.
>
>
>static void
>gen7_upload_urb(struct brw_context *brw)
>{
> struct intel_context *intel = &brw->intel;
> /* Total space for entries is URB size - 16kB for push constants */
> int handle_region_size = (brw->urb.size - 16) * 1024; /* bytes */
>
> /* CACHE_NEW_VS_PROG */
> brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1);
>
> int nr_vs_entries = handle_region_size / (brw->urb.vs_size * 64);
> if (nr_vs_entries > brw->urb.max_vs_entries)
> nr_vs_entries = brw->urb.max_vs_entries;
>
> /* If the number of URB Allocation Size is smaller than 9 512 bit
> * units set the number or URB to Entries to 32
> */
>#define GEN7_URB_VS_MIN_ENTRIES 32
> if(brw->urb.vs_size < 9)
> nr_vs_entries = GEN7_URB_VS_MIN_ENTRIES;
>
>
>
>Douglas
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ooh this is a good fix. Can you bounce it over to the meas list for inclusion?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Valleyview: 3DSTATE_URB_VS Minimum URB Entries
2012-07-03 19:27 ` Jesse Barnes
@ 2012-07-04 5:50 ` Cheah, Douglas
0 siblings, 0 replies; 3+ messages in thread
From: Cheah, Douglas @ 2012-07-04 5:50 UTC (permalink / raw)
To: Jesse Barnes, intel-gfx
Will do, I am not familiar with the procedure in Mesa but I will post a patch in their mailing list requesting for it to be included.
I just had a chance to test this on a couple more mesa demo applications and 3DMarkmobile that also exhibit a lot of corruptions in Valleyview. The fix work well for those application as well.
Douglas
-----Original Message-----
From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
Sent: Wednesday, July 04, 2012 3:28 AM
To: Cheah, Douglas; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Valleyview: 3DSTATE_URB_VS Minimum URB Entries
"Cheah, Douglas" <douglas.cheah@intel.com> wrote:
>Hello folks,
>
>I am seeing corruption when running spectex from mesa demos which looks
>like vertex being randomly clipped on Valleyview, however spectex works
>fine on Ivy Bridge.
>
>After tracing down the codes I realize that the current Mesa driver
>would program the maximum number or URB entries (512 Valleyview)
>whenever possible. This conflict with the 3D pipeline PRM where it
>states there is a programming restriction if the URB Entry Allocation
>Size is less than 9 URB entries then total entries should be program to
>32. After modifying the codes to meet the restriction I was able to run
>spectex without corruption on Valleyview, pretty surprise that Ivy
>Bridge did not have this problem.
>
>Here is the code snippet that I have changed which is at this point a
>quick hack and not upstream worthy as you can see the macro is not even
>properly defined in brw_defeines.h. Appreciate if I could get opinions
>from folks who are more familiar with Mesa and more experience with the
>graphic core.
>
>
>static void
>gen7_upload_urb(struct brw_context *brw) {
> struct intel_context *intel = &brw->intel;
> /* Total space for entries is URB size - 16kB for push constants */
> int handle_region_size = (brw->urb.size - 16) * 1024; /* bytes */
>
> /* CACHE_NEW_VS_PROG */
> brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1);
>
> int nr_vs_entries = handle_region_size / (brw->urb.vs_size * 64);
> if (nr_vs_entries > brw->urb.max_vs_entries)
> nr_vs_entries = brw->urb.max_vs_entries;
>
> /* If the number of URB Allocation Size is smaller than 9 512 bit
> * units set the number or URB to Entries to 32
> */
>#define GEN7_URB_VS_MIN_ENTRIES 32
> if(brw->urb.vs_size < 9)
> nr_vs_entries = GEN7_URB_VS_MIN_ENTRIES;
>
>
>
>Douglas
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ooh this is a good fix. Can you bounce it over to the meas list for inclusion?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-07-04 5:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-03 4:07 Valleyview: 3DSTATE_URB_VS Minimum URB Entries Cheah, Douglas
2012-07-03 19:27 ` Jesse Barnes
2012-07-04 5:50 ` Cheah, Douglas
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.