On Thu, 2014-07-24 at 13:52 -0400, Alex Deucher wrote: > On Thu, Jul 24, 2014 at 12:05 PM, Jan Vesely <jan.ves...@rutgers.edu> wrote: > > > > On Thu, 2014-07-24 at 17:07 +0200, Marek Olšák wrote: > >> Sorry, GL 3.1 actually only requires 1024 vec4s. The UBO extension > >> spec contains a mistake. > >> > >> Marek > >> > >> On Thu, Jul 24, 2014 at 4:55 PM, Marek Olšák <mar...@gmail.com> wrote: > >> > OpenGL 3.1 requires 4096 vec4s (65536 bytes) per constant buffer and > >> > the hardware supports 16 constant buffers. I'm not sure what the > >> > "constant registers" are, but they cannot have anything to do with the > >> > constant buffer limit, because otherwise we wouldn't be able to meet > >> > the requirement for uniform buffer objects. > > > > Hm, it's rather confusing. > > ch. 2.5 describes 512 128bit Constant Registers (W by host R by GPU) in ALU > > state. > > section 4.6.4 mentions that there are 256 128-bit constants (in constant > > file) available in DX9 mode, > > and 1-4096 128bit in memory constants in dx10 mode. (I guess that's where > > the 4096 value comes from) > > > > Then there's constant cache of 64 128 bit constants, which uses the CR > > mentioned above, > > and I believe is used to pass kernel arguments by clover. > > VLIW4/5 asic also have a kcache which is basically a small cache for > access to a subset of the memory backed DX10 constant buffer. > > > > > I know little about OpenGL, what are these different ways to do the same > > thing good for? > > There's not really different ways. On r6xx/r7xx there was an on-chip > buffer (CFILE) were you could write constants since DX9 had a fixed > size constant file. Storing them in sram on-chip is fast, but takes > die space. With DX10, constants were stored in memory. From > evergreen going forward, the hardware only supports DX10 style memory > backed constant buffers. So if you take the CFILE out of the picture, > there's only one way to access constant buffers.
thank you for the explanation Jan > > Alex > > > > > > thanks > > Jan > > > >> > > >> > Marek > >> > > >> > On Thu, Jul 24, 2014 at 4:05 PM, Jan Vesely <jan.ves...@rutgers.edu> > >> > wrote: > >> >> On Thu, 2014-07-24 at 06:35 -0700, Tom Stellard wrote: > >> >>> On Thu, Jul 24, 2014 at 01:09:49PM +0200, Marek Olšák wrote: > >> >>> > Isn't this redundant with get_shader_param(PIPE_SHADER_COMPUTE, > >> >>> > PIPE_SHADER_CAP_MAX_CONSTS) * 16? > >> >>> > > >> >>> > >> >>> This is what clover was using, but I was confused about what the value > >> >>> was supposed to represent. Now, I think I understand (number of 4 x > >> >>> 32-bit > >> >>> constants). I can use this instead. > >> >> > >> >> Is the value for r600 hw misreported then? The manuals for R600/EG/NI > >> >> say there are 512 such registers. Yet the driver reports 4096. > >> >> See the attached patch. > >> >> > >> >> Jan > >> >> > >> >>> > >> >>> -Tom > >> >>> > Marek > >> >>> > > >> >>> > On Thu, Jul 24, 2014 at 3:05 AM, Tom Stellard > >> >>> > <thomas.stell...@amd.com> wrote: > >> >>> > > --- > >> >>> > > src/gallium/docs/source/screen.rst | 2 ++ > >> >>> > > src/gallium/include/pipe/p_defines.h | 3 ++- > >> >>> > > 2 files changed, 4 insertions(+), 1 deletion(-) > >> >>> > > > >> >>> > > diff --git a/src/gallium/docs/source/screen.rst > >> >>> > > b/src/gallium/docs/source/screen.rst > >> >>> > > index 830a1a5..219c9f9 100644 > >> >>> > > --- a/src/gallium/docs/source/screen.rst > >> >>> > > +++ b/src/gallium/docs/source/screen.rst > >> >>> > > @@ -334,6 +334,8 @@ pipe_screen::get_compute_param. > >> >>> > > Value type: ``uint32_t`` > >> >>> > > * ``PIPE_COMPUTE_CAP_IMAGES_SUPPORTED``: Whether images are > >> >>> > > supported > >> >>> > > non-zero means yes, zero means no. Value type: ``uint32_t`` > >> >>> > > +* ``PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE``: The maximum size > >> >>> > > in bytes > >> >>> > > + of a constant buffer. Value type: ``uint64_t`` > >> >>> > > > >> >>> > > .. _pipe_bind: > >> >>> > > > >> >>> > > diff --git a/src/gallium/include/pipe/p_defines.h > >> >>> > > b/src/gallium/include/pipe/p_defines.h > >> >>> > > index 43bb1f5..78709b9 100644 > >> >>> > > --- a/src/gallium/include/pipe/p_defines.h > >> >>> > > +++ b/src/gallium/include/pipe/p_defines.h > >> >>> > > @@ -651,7 +651,8 @@ enum pipe_compute_cap > >> >>> > > PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE, > >> >>> > > PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY, > >> >>> > > PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS, > >> >>> > > - PIPE_COMPUTE_CAP_IMAGES_SUPPORTED > >> >>> > > + PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, > >> >>> > > + PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE > >> >>> > > }; > >> >>> > > > >> >>> > > /** > >> >>> > > -- > >> >>> > > 1.8.1.5 > >> >>> > > > >> >>> > > _______________________________________________ > >> >>> > > mesa-dev mailing list > >> >>> > > mesa-dev@lists.freedesktop.org > >> >>> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> >>> > _______________________________________________ > >> >>> > mesa-dev mailing list > >> >>> > mesa-dev@lists.freedesktop.org > >> >>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> >>> _______________________________________________ > >> >>> mesa-dev mailing list > >> >>> mesa-dev@lists.freedesktop.org > >> >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> >> > >> >> -- > >> >> Jan Vesely <jan.ves...@rutgers.edu> > > > > -- > > Jan Vesely <jan.ves...@rutgers.edu> > > > > -- > > Jan Vesely <jan.ves...@rutgers.edu> > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- Jan Vesely <jan.ves...@rutgers.edu>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
