[Mesa-dev] [PATCH 1/3] gallium: Add PIPE_COMPUTE_CAP_MAX_CONSTANT_BUFFER_SIZE

Thu Jul 24 15:30:07 PDT 2014

On Thu, 2014-07-24 at 13:52 -0400, Alex Deucher wrote:
> On Thu, Jul 24, 2014 at 12:05 PM, Jan Vesely <jan.vesely at 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 <maraeo at 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.vesely at 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.stellard at 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 at lists.freedesktop.org
> >> >>> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >>> > _______________________________________________
> >> >>> > mesa-dev mailing list
> >> >>> > mesa-dev at lists.freedesktop.org
> >> >>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >>> _______________________________________________
> >> >>> mesa-dev mailing list
> >> >>> mesa-dev at lists.freedesktop.org
> >> >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >> >>
> >> >> --
> >> >> Jan Vesely <jan.vesely at rutgers.edu>
> >
> > --
> > Jan Vesely <jan.vesely at rutgers.edu>
> >
> > --
> > Jan Vesely <jan.vesely at rutgers.edu>
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >

-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140724/ffc7deca/attachment-0001.sig>