* Trying to understand the URB code
@ 2011-04-07 5:01 Kenneth Graunke
2011-04-07 8:24 ` Zou, Nanhai
0 siblings, 1 reply; 3+ messages in thread
From: Kenneth Graunke @ 2011-04-07 5:01 UTC (permalink / raw)
To: Zou, Nanhai; +Cc: intel-gfx
Hi Nanhai,
I'm trying to understand how the Gen6 URB setup works, and I had some
questions...
if (IS_GT1(intel->intelScreen->deviceID)) {
urb_size = 32 * 1024;
max_urb_entry = 128;
} else {
urb_size = 64 * 1024;
max_urb_entry = 256;
}
I see in vol5c.5 that GT1 has 32kB of URB space and GT2 has 64kB, so
urb_size must be the total size of the URB. But what is max_urb_entry?
Where do 128 and 256 come from?
brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1);
It looks like brw->vs.prog_data->urb_entry_size is the size of a single
VUE, which depends on the number of input/outputs in the particular
vertex shader being used.
So, brw->urb.vs_size is also the size of a VUE, but at least 1.
What are the units here? The number of 1024-bit blocks? (I'm looking
at 3DSTATE_URB in vol2a of the bspec...)
brw->urb.nr_vs_entries = max_urb_entry;
brw->urb.nr_gs_entries = max_urb_entry;
if (2 * brw->urb.vs_size * brw->urb.nr_vs_entries > urb_size)
brw->urb.nr_vs_entries = brw->urb.nr_gs_entries =
(urb_size ) / (2 * brw->urb.vs_size);
Here it looks like you're trying to allocate half of the URB to the VS,
and half to the GS. I'm confused by the units, though: if vs_size is in
1024-bit (128-byte) blocks and urb_size is in bytes, don't we need to
multiply vs_size by 128?
I think the above code could be simplified to:
int urb_entries = urb_size / (2 * brw->urb.vs_size * 128);
brw->urb.nr_vs_entries = brw->urb.nr_gs_entries = MIN2(urb_entries,
max_urb_entry);
What do you think?
Thanks for the help.
--Kenneth
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Trying to understand the URB code
2011-04-07 5:01 Trying to understand the URB code Kenneth Graunke
@ 2011-04-07 8:24 ` Zou, Nanhai
2011-04-08 19:03 ` Ian Romanick
0 siblings, 1 reply; 3+ messages in thread
From: Zou, Nanhai @ 2011-04-07 8:24 UTC (permalink / raw)
To: Kenneth Graunke; +Cc: intel-gfx
Hi Ken,
URB allocation on gen6 is different than previous gens.
On previous gen, there is a total size urb for many stages of VS GS CLIP SF.
So driver has to decide how much urb to allocate for each stage.
On gen6 only GS and VS will share an urb of 64k(32k on GT1)
urb_entry_number also has a limit, check 3DSTATE_URB command.
The more urb entry number we have, the more current threads can spawn.
But
We should make sure
VS urb size = single_urb_size * gs_urb_entry
+
GS urb size = single_urb_size * vs_urb_entry
< total_urb_size
In most case, this is ok, unless we have a huge single_urb_size.
Since we are always using GS pass through mode for now.
The number for GS urb dose not matter.
So allocate more urb size for VS, less for GS may be better for huge urb_size
But consider we will support GS shader later and huge urb_size case is very rare,
I separate urb equally for GS and VS.
Thanks
Zou Nan hai
>>-----Original Message-----
>>From: Kenneth Graunke [mailto:kenneth@whitecape.org]
>>Sent: 2011年4月7日 13:01
>>To: Zou, Nanhai
>>Cc: intel-gfx@lists.freedesktop.org
>>Subject: Trying to understand the URB code
>>
>>Hi Nanhai,
>>
>>I'm trying to understand how the Gen6 URB setup works, and I had some
>>questions...
>>
>> if (IS_GT1(intel->intelScreen->deviceID)) {
>> urb_size = 32 * 1024;
>> max_urb_entry = 128;
>> } else {
>> urb_size = 64 * 1024;
>> max_urb_entry = 256;
>> }
>>
>>I see in vol5c.5 that GT1 has 32kB of URB space and GT2 has 64kB, so
>>urb_size must be the total size of the URB. But what is max_urb_entry?
>> Where do 128 and 256 come from?
>>
>> brw->urb.vs_size = MAX2(brw->vs.prog_data->urb_entry_size, 1);
>>
>>It looks like brw->vs.prog_data->urb_entry_size is the size of a single
>>VUE, which depends on the number of input/outputs in the particular
>>vertex shader being used.
>>
>>So, brw->urb.vs_size is also the size of a VUE, but at least 1.
>>What are the units here? The number of 1024-bit blocks? (I'm looking
>>at 3DSTATE_URB in vol2a of the bspec...)
>>
>> brw->urb.nr_vs_entries = max_urb_entry;
>> brw->urb.nr_gs_entries = max_urb_entry;
>>
>> if (2 * brw->urb.vs_size * brw->urb.nr_vs_entries > urb_size)
>> brw->urb.nr_vs_entries = brw->urb.nr_gs_entries =
>> (urb_size ) / (2 * brw->urb.vs_size);
>>
>>Here it looks like you're trying to allocate half of the URB to the VS,
>>and half to the GS. I'm confused by the units, though: if vs_size is in
>>1024-bit (128-byte) blocks and urb_size is in bytes, don't we need to
>>multiply vs_size by 128?
>>
>>I think the above code could be simplified to:
>>
>>int urb_entries = urb_size / (2 * brw->urb.vs_size * 128);
>>brw->urb.nr_vs_entries = brw->urb.nr_gs_entries = MIN2(urb_entries,
>>max_urb_entry);
>>
>>What do you think?
>>
>>Thanks for the help.
>>--Kenneth
_______________________________________________
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: Trying to understand the URB code
2011-04-07 8:24 ` Zou, Nanhai
@ 2011-04-08 19:03 ` Ian Romanick
0 siblings, 0 replies; 3+ messages in thread
From: Ian Romanick @ 2011-04-08 19:03 UTC (permalink / raw)
To: Zou, Nanhai; +Cc: intel-gfx
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/07/2011 01:24 AM, Zou, Nanhai wrote:
> Hi Ken,
> URB allocation on gen6 is different than previous gens.
> On previous gen, there is a total size urb for many stages of VS GS CLIP SF.
> So driver has to decide how much urb to allocate for each stage.
>
> On gen6 only GS and VS will share an urb of 64k(32k on GT1)
>
> urb_entry_number also has a limit, check 3DSTATE_URB command.
Ken and I did some research on this yesterday. The bspec says the valid
range for the VS is [24, 256] on GT2 and [24, 128] on GT1. For the GS
it says the valid range is [0, 256] on GT2 and [0, 254] on GT1. I can't
believe that 254 is correct.
> The more urb entry number we have, the more current threads can spawn.
>
> But
> We should make sure
> VS urb size = single_urb_size * gs_urb_entry
> +
> GS urb size = single_urb_size * vs_urb_entry
> < total_urb_size
>
> In most case, this is ok, unless we have a huge single_urb_size.
>
> Since we are always using GS pass through mode for now.
> The number for GS urb dose not matter.
> So allocate more urb size for VS, less for GS may be better for huge urb_size
>
> But consider we will support GS shader later and huge urb_size case is very rare,
> I separate urb equally for GS and VS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2fXAYACgkQX1gOwKyEAw+RSQCdFiIxdyeKmytlovCEO3w3RIIA
uN4An1POHfJ3J4fzKZnGWbHLb4eZBwnM
=xpu8
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-04-08 19:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-07 5:01 Trying to understand the URB code Kenneth Graunke
2011-04-07 8:24 ` Zou, Nanhai
2011-04-08 19:03 ` Ian Romanick
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).