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

[Alex Deucher]

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.

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
>