From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cheah, Douglas" Subject: Valleyview: 3DSTATE_URB_VS Minimum URB Entries Date: Tue, 3 Jul 2012 04:07:35 +0000 Message-ID: <56F47131CD0B6E46806703F9356EF8D722105FEE@PGSMSX101.gar.corp.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0077129883==" Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 06A009E78F for ; Mon, 2 Jul 2012 21:09:03 -0700 (PDT) Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org --===============0077129883== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_56F47131CD0B6E46806703F9356EF8D722105FEEPGSMSX101garcor_" --_000_56F47131CD0B6E46806703F9356EF8D722105FEEPGSMSX101garcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello folks, I am seeing corruption when running spectex from mesa demos which looks lik= e vertex being randomly clipped on Valleyview, however spectex works fine o= n Ivy Bridge. After tracing down the codes I realize that the current Mesa driver would p= rogram the maximum number or URB entries (512 Valleyview) whenever possibl= e. This conflict with the 3D pipeline PRM where it states there is a progra= mming restriction if the URB Entry Allocation Size is less than 9 URB entri= es 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 Valle= yview, 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 w= ho 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 =3D &brw->intel; /* Total space for entries is URB size - 16kB for push constants */ int handle_region_size =3D (brw->urb.size - 16) * 1024; /* bytes */ /* CACHE_NEW_VS_PROG */ brw->urb.vs_size =3D MAX2(brw->vs.prog_data->urb_entry_size, 1); int nr_vs_entries =3D handle_region_size / (brw->urb.vs_size * 64); if (nr_vs_entries > brw->urb.max_vs_entries) nr_vs_entries =3D 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 =3D GEN7_URB_VS_MIN_ENTRIES; Douglas --_000_56F47131CD0B6E46806703F9356EF8D722105FEEPGSMSX101garcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello folks,

I am seeing corruption when running spectex from mes= a demos which looks like vertex being randomly clipped on Valleyview, howev= er spectex works fine on Ivy Bridge.

After tracing down the codes I realize that the curr= ent Mesa driver would program the maximum number or URB entries (512 Valley= view) 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 ent= ries should be program to 32. After modifying the codes to meet the restric= tion I was able to run spectex without corruption on Valleyview, pretty sur= prise that Ivy Bridge did not have this problem.

Here is the code snippet that I have changed which i= s at this point a quick hack and not upstream worthy as you can see the mac= ro is not even properly defined in brw_defeines.h. Appreciate if I could ge= t opinions from folks who are more familiar with Mesa and more experience with the graphic core.

static<= span style=3D"font-size:9.0pt;font-family:"Courrier New""> void

gen7_upload_urb(struct brw_context *brw)

{

struct intel_context *intel =3D &b= rw->intel;

/* Total space for entries is URB size - 16kB= for push constants */

int handle_region_size =3D (brw->ur= b.size - 16) * 1024; /* bytes */

/* CACHE_NEW_VS_PROG */

brw->urb.vs_= size =3D MAX= 2(brw->vs.prog_data->urb_entry_size, 1);

int nr_vs_entries =3D handle_region_si= ze / (brw->urb.vs_size * 64);

if (nr_vs_entries > brw->urb.max= _vs_entries)

&nbs= p; nr_vs_entries =3D brw->urb.max_vs_entries;

/* If the number of URB Allocation Size is sm= aller than 9 512 bit

&n= bsp; * units set the number or URB to Entries to 32

&n= bsp; */

#define GEN7_U= RB_VS_MIN_ENTRIES 32

if(brw->urb.vs_size < 9)

&nbs= p; nr_vs_entries =3D GEN7_URB_VS_MIN_ENTRIES;=

Douglas

--_000_56F47131CD0B6E46806703F9356EF8D722105FEEPGSMSX101garcor_-- --===============0077129883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0077129883==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: Valleyview: 3DSTATE_URB_VS Minimum URB Entries Date: Tue, 03 Jul 2012 12:27:49 -0700 Message-ID: <95f2bebc-0363-4dbd-9ea1-5a143209a6a1@email.android.com> References: <56F47131CD0B6E46806703F9356EF8D722105FEE@PGSMSX101.gar.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by gabe.freedesktop.org (Postfix) with SMTP id CD9D49E804 for ; Tue, 3 Jul 2012 12:27:41 -0700 (PDT) In-Reply-To: <56F47131CD0B6E46806703F9356EF8D722105FEE@PGSMSX101.gar.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: "Cheah, Douglas" , "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org "Cheah, Douglas" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cheah, Douglas" Subject: Re: Valleyview: 3DSTATE_URB_VS Minimum URB Entries Date: Wed, 4 Jul 2012 05:50:24 +0000 Message-ID: <56F47131CD0B6E46806703F9356EF8D7221079C8@PGSMSX101.gar.corp.intel.com> References: <56F47131CD0B6E46806703F9356EF8D722105FEE@PGSMSX101.gar.corp.intel.com> <95f2bebc-0363-4dbd-9ea1-5a143209a6a1@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 976709E921 for ; Tue, 3 Jul 2012 22:50:41 -0700 (PDT) In-Reply-To: <95f2bebc-0363-4dbd-9ea1-5a143209a6a1@email.android.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Jesse Barnes , "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org 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" 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