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. 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 > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
