Re: [Mesa-dev] Summer of Code ideas (maybe just an idea wishlist?)
Are you suggesting bringing OpenCL support for Adreno gpus and using softfloat? On Thu, Mar 26, 2015 at 8:50 PM, Rob Clark wrote: > On Thu, Mar 26, 2015 at 3:10 PM, Ilia Mirkin wrote: > > On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand > wrote: > >> On Thu, Mar 26, 2015 at 12:00 PM, Aditya Avinash > >> wrote: > >>> I mean, implementing fp64 on single precision systems. > >> > >> Ok, That makes more sense! Having lowering passes for various FP64 > >> operations would be great. > > > > We should make sure that there are customers of such work. It only > > makes sense to do this when everything else but FP64 are supported for > > GL 4.0 (including tess). r600 (eg/ni) is an obvious customer, although > > that may be easier to do in sb (I believe GlennK has been looking at > > it, not sure how far he's gotten). Other than that... not sure. Could > > be that Adreno A420 can do tess && has no native fp64 support, still > > need to figure that out (hasn't been RE'd yet). > > fwiw, fp64 lowering is almost certainly useful for a3xx when we get to > the point of doing compute.. > > (on that topic, TGSI or NIR support for clover would be kinda awesome > to get compute going on some drivers other than radeon.. probably TGSI > would be more immediately useful for more drivers, but not sure how > much would need to be added to TGSI, and NIR seems to be more > future-proof..) > > BR, > -R > > > > > > -ilia > > ___ > > 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 > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Summer of Code ideas (maybe just an idea wishlist?)
What about Nouveau and Intel? On Thu, Mar 26, 2015 at 3:10 PM, Ilia Mirkin wrote: > On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand > wrote: > > On Thu, Mar 26, 2015 at 12:00 PM, Aditya Avinash > > wrote: > >> I mean, implementing fp64 on single precision systems. > > > > Ok, That makes more sense! Having lowering passes for various FP64 > > operations would be great. > > We should make sure that there are customers of such work. It only > makes sense to do this when everything else but FP64 are supported for > GL 4.0 (including tess). r600 (eg/ni) is an obvious customer, although > that may be easier to do in sb (I believe GlennK has been looking at > it, not sure how far he's gotten). Other than that... not sure. Could > be that Adreno A420 can do tess && has no native fp64 support, still > need to figure that out (hasn't been RE'd yet). > > -ilia > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Summer of Code ideas (maybe just an idea wishlist?)
Do you know anyone working on it? On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand wrote: > On Thu, Mar 26, 2015 at 12:00 PM, Aditya Avinash > wrote: > > I mean, implementing fp64 on single precision systems. > > Ok, That makes more sense! Having lowering passes for various FP64 > operations would be great. > --Jason > > > On Thu, Mar 26, 2015 at 2:59 PM, Jason Ekstrand > > wrote: > >> > >> On Thu, Mar 26, 2015 at 11:20 AM, Aditya Avinash > >> wrote: > >> > Hi, > >> > I would like to softfloat for GSOC. Is anyone working on it? > >> > Thank you!! :) > >> > >> What do you mean by softfloat? If you're talking about doing software > >> floating-point on the GPU, I don't think that's a thing. GPUs > >> frequently don't support integers, but they all support float. > >> --Jason > > > > > > > > > > -- > > Regards, > > Aditya Atluri, > > USA. > > > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Summer of Code ideas (maybe just an idea wishlist?)
I mean, implementing fp64 on single precision systems. On Thu, Mar 26, 2015 at 2:59 PM, Jason Ekstrand wrote: > On Thu, Mar 26, 2015 at 11:20 AM, Aditya Avinash > wrote: > > Hi, > > I would like to softfloat for GSOC. Is anyone working on it? > > Thank you!! :) > > What do you mean by softfloat? If you're talking about doing software > floating-point on the GPU, I don't think that's a thing. GPUs > frequently don't support integers, but they all support float. > --Jason > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Summer of Code ideas (maybe just an idea wishlist?)
Hi, I would like to softfloat for GSOC. Is anyone working on it? Thank you!! :) On Tue, Mar 24, 2015 at 12:16 AM, Kenneth Graunke wrote: > On Monday, March 23, 2015 05:02:51 PM Aaron Watry wrote: > > On a related note, > > > > Has anyone ported shader-db over to working on R600/RadeonSI/ > non-intel>? I've been meaning to take a look at the NIR->TGSI pass and > see > > if there's an easy way to hook it up to the radeon drivers, but I wanted > to > > be able to get shader-db up and running on that hardware first so that we > > could get some before/after numbers (I'm assuming that R600 w/o SB will > be > > the main radeon driver that benefits, but I'd love to be proven wrong). > > > > --Aaron > > It shouldn't be hard to get working. > > The shader-db runner doesn't actually draw anything, so you need to > precompile assembly code at glLinkProgram time, making some assumptions > about the GL state that will be used. We manage to guess correctly > most of the time on modern Intel hardware. > > Beyond that, you just need to have the driver emit a few messages via > KHR_debug: > >static GLuint msg_id = 0; >_mesa_gl_debug(ctx, &msg_id, > MESA_DEBUG_SOURCE_SHADER_COMPILER, > MESA_DEBUG_TYPE_OTHER, > MESA_DEBUG_SEVERITY_NOTIFICATION, > "%s shader: %d", > type_of_shader, /* "FS", "VS" and the like */ > num_instructions); > > That should be all you need for the original shader-db which most of > the Intel folks use (git://anongit.freedesktop.org/mesa/shader-db). > > Eric has a new reboot of the project that uses apitraces of files rather > than Piglit shader_test files. The Broadcom vc4 apparently has so much > non-orthagonal state that it's impractical to guess the state during a > precompile, so he wanted to use the actual state from the trace. > > Everyone else has kept using the original version because it's *much* > faster - on my Haswell, it only takes about 2-3 minutes to process > ~24,000 shaders from ~290 applications. > > I assume Radeon and Nouveau can probably guess most state correctly, > so using the original shader-db would make more sense. Freedreno > might have to use Eric's apitrace based solution. > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Summer of Code ideas (maybe just an idea wishlist?)
Hi, I am looking for a GSOC project. I am interested in working on driver. Hardware available: All AMD gpus (+1 APU) NVIDIA k40, GTX780, Quadro 3500, GT755M Intel: Haswell (buying on next pay date) On Wed, Mar 18, 2015 at 2:58 PM, Matt Turner wrote: > On Thu, Mar 12, 2015 at 9:46 PM, Matt Turner wrote: > > Here are some ideas I think might be reasonable GSoC ideas. > > > > - GLSL linking in NIR > > - Would allow us to stop doing optimizations and other expensive > > things on GLSL IR > > Ian said this should wait until everything is using NIR so that we > don't have two linkers. :) > > > - SSA in the i965/fs backend, and an SSA-based register allocator > > Jason thought this was too hard as a GSoC project. Probably right. > > > - Improve instruction scheduling in i965 (Nouveau has this on the > > Wiki as well. Maybe potential for code reuse) > > This still seems like a good GSoC-worthy project. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/29] glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)
I am sorry. I don't mean it in conventional sense. I'll describe it soon. On Sunday, February 8, 2015, Matt Turner wrote: > On Sun, Feb 8, 2015 at 3:45 PM, Aditya Avinash > wrote: > > I think using softfloat at GLSL compilation stage will be a good idea > > (atleast saves time on runtime compiler). Having both soft and hard > floats > > in the binary can help as you can discard which ever you want depending > on > > the backend. This also removes the stress on runtime compiler. > > This doesn't make any sense. > > We don't make "binaries" in the conventional sense. > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/29] glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)
On Sun, Feb 8, 2015 at 6:30 PM, Matt Turner wrote: > On Sun, Feb 8, 2015 at 2:51 PM, Dave Airlie wrote: > > On 9 February 2015 at 08:44, Aditya Avinash > wrote: > >> Ya. I just want to know that part "only some r600". > >> I believe some of the nv0 cards doesn't support double. You have any > ideas > >> or suggestions to make it possible? > > > > For AMD > > http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units > > > > has what cards directly support double precision for r600/700/evergreen > > > > The plan is to implement a soffloat library like the fglrx drivers do > for the > > GPUs that don't do doubles just to satisfy the GL4.0 requirement. > > i965 hardware needs varying degrees of help to do doubles (the > round-down instruction doesn't work on doubles, for instance), so > we'll need some amount of this. > > But I'm curious about what you think the cost:benefit is to writing > what sounds like a potentially significant amount of code [1] to > support doubles on old cards? For a feature that no one seems to use, > no less. > I think the current sweet spot for AMD GPUs is NI. I can't buy less than that on Amazon (high end!). Full support for SI to start with and NI would be enough for now. Is it possible to borrow the techniques from OpenCL as it should support doubles for all compatible cards? I think using softfloat at GLSL compilation stage will be a good idea (atleast saves time on runtime compiler). Having both soft and hard floats in the binary can help as you can discard which ever you want depending on the backend. This also removes the stress on runtime compiler. > > Actually, looking at the link you gave, Wikipedia says they just > support GL 3.3. Does fglrx expose ARB_gpu_shader_fp64 but not GL 4.0 > on them? > > [1] Take for instance a WIP implementation of floor: > > http://cgit.freedesktop.org/~tpalli/mesa/commit/?h=fp64_floor&id=2e3909057e269b3466ceef8d2573abf82078e5c6 > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/29] glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)
If softfloat is implemented, where can be a right place to put it? On Sun, Feb 8, 2015 at 6:17 PM, Ilia Mirkin wrote: > On Sun, Feb 8, 2015 at 5:51 PM, Dave Airlie wrote: > > On 9 February 2015 at 08:44, Aditya Avinash > wrote: > >> Ya. I just want to know that part "only some r600". > >> I believe some of the nv0 cards doesn't support double. You have any > ideas > >> or suggestions to make it possible? > > > > For AMD > > http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units > > > > has what cards directly support double precision for r600/700/evergreen > > > > The plan is to implement a soffloat library like the fglrx drivers do > for the > > GPUs that don't do doubles just to satisfy the GL4.0 requirement. > > > > Whether we implement this in GLSL, NIR or in the backends is currently > > an open question. > > > > Not sure what the nvidia limitations are if any. > > All of the Fermi+ cards have pretty full hw support. The only lacking > area is that they only compute the upper 32 bits of a RSQ and RCP > operation, but that's solvable with a bit of Newton-Raphson magic. > > The G200 chip (NVA0) is the only Tesla-family chip which has some fp64 > support, but it's missing some useful operations, like any sort of > sqrt or division-related functionality. But it can add/multiply. Some > sort of partial softfloat may be useful there, but... it can be > difficult to care about the single high-end chip of the old family. > > -ilia > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/29] glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)
Yes. All the low end cards of AMD does not support native double precision. (Until the most recent SI). Are there any good papers or documentation to do soffloat? Or emulate fglrx stuff? On Sun, Feb 8, 2015 at 5:51 PM, Dave Airlie wrote: > On 9 February 2015 at 08:44, Aditya Avinash > wrote: > > Ya. I just want to know that part "only some r600". > > I believe some of the nv0 cards doesn't support double. You have any > ideas > > or suggestions to make it possible? > > For AMD > http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units > > has what cards directly support double precision for r600/700/evergreen > > The plan is to implement a soffloat library like the fglrx drivers do for > the > GPUs that don't do doubles just to satisfy the GL4.0 requirement. > > Whether we implement this in GLSL, NIR or in the backends is currently > an open question. > > Not sure what the nvidia limitations are if any. > > Dave. > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/29] glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)
Ya. I just want to know that part "only some r600".
I believe some of the nv0 cards doesn't support double. You have any ideas
or suggestions to make it possible?
On Sun, Feb 8, 2015 at 3:28 PM, Ilia Mirkin wrote:
> Yes. nvc0+ (fermi+) has fp64 support [and the G200 chip also has a
> bunch, tbd whether we'll bother supporting it]. radeon si/cik also has
> it. Only some r600 eg/ni-based cards have hw support (generally
> speaking, the higher end ones), the rest will have to emulate it. I
> believe that intel gen7 (ivb) and later have enough to make it happen
> too.
>
> On Sun, Feb 8, 2015 at 3:21 PM, Aditya Avinash
> wrote:
> > Interesting... Does the actual hardware support double? (atleast for nv0)
> > Thank you!
> >
> > On Sun, Feb 8, 2015 at 12:20 PM, Ilia Mirkin
> wrote:
> >>
> >> It all works fine on nvc0 and softpipe with my branch at
> >>
> >> https://github.com/imirkin/mesa/commits/fp64-4
> >>
> >> This branch also includes Dave's preliminary work on r600/cayman, not
> >> sure how far along it is, I believe it's still missing a few things.
> >> The nvc0 implementation needs a few more finishing touches for
> >> handling RCP and RSQ better (just adding a couple of steps of
> >> Newton-Raphson, since the hw only computes 32 bits of the 64-bit
> >> result).
> >>
> >>
> >> On Sun, Feb 8, 2015 at 12:04 PM, Aditya Avinash
> >> wrote:
> >> > Hi,
> >> > How far is glsl compiler working for fp64 shader?
> >> >
> >> > On Sun, Feb 8, 2015 at 4:00 AM, Ilia Mirkin
> >> > wrote:
> >> >>
> >> >> From: Dave Airlie
> >> >>
> >> >> v2: add define bit (Tapani Pälli)
> >> >>
> >> >> Patch makes following Piglit tests pass:
> >> >>arb_gpu_shader_fp64/preprocessor/define.vert
> >> >>arb_gpu_shader_fp64/preprocessor/define.frag
> >> >>
> >> >> Reviewed-by: Ian Romanick
> >> >> Signed-off-by: Dave Airlie
> >> >> Reviewed-by: Matt Turner
> >> >> ---
> >> >> src/glsl/glcpp/glcpp-parse.y| 3 +++
> >> >> src/glsl/glsl_parser_extras.cpp | 1 +
> >> >> src/glsl/glsl_parser_extras.h | 2 ++
> >> >> src/glsl/standalone_scaffolding.cpp | 1 +
> >> >> 4 files changed, 7 insertions(+)
> >> >>
> >> >> diff --git a/src/glsl/glcpp/glcpp-parse.y
> >> >> b/src/glsl/glcpp/glcpp-parse.y
> >> >> index e5bebe5..c2f5223 100644
> >> >> --- a/src/glsl/glcpp/glcpp-parse.y
> >> >> +++ b/src/glsl/glcpp/glcpp-parse.y
> >> >> @@ -2445,6 +2445,9 @@
> >> >> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser,
> >> >> intmax_t
> >> >> versio
> >> >> if (extensions->ARB_gpu_shader5)
> >> >> add_builtin_define(parser, "GL_ARB_gpu_shader5", 1);
> >> >>
> >> >> + if (extensions->ARB_gpu_shader_fp64)
> >> >> + add_builtin_define(parser,
> "GL_ARB_gpu_shader_fp64",
> >> >> 1);
> >> >> +
> >> >> if (extensions->AMD_vertex_shader_layer)
> >> >> add_builtin_define(parser,
> >> >> "GL_AMD_vertex_shader_layer",
> >> >> 1);
> >> >>
> >> >> diff --git a/src/glsl/glsl_parser_extras.cpp
> >> >> b/src/glsl/glsl_parser_extras.cpp
> >> >> index ccdf031..cb19ce1 100644
> >> >> --- a/src/glsl/glsl_parser_extras.cpp
> >> >> +++ b/src/glsl/glsl_parser_extras.cpp
> >> >> @@ -527,6 +527,7 @@ static const _mesa_glsl_extension
> >> >> _mesa_glsl_supported_extensions[] = {
> >> >> EXT(ARB_fragment_coord_conventions, true, false,
> >> >> ARB_fragment_coord_conventions),
> >> >> EXT(ARB_fragment_layer_viewport,true, false,
> >> >> ARB_fragment_layer_viewport),
> >> >> EXT(ARB_gpu_shader5,true, false,
> >> >> ARB_gpu_shader5),
> >> >> + EXT(ARB_gpu_shader_fp64,true, false,
> >> >> ARB_gpu_shader_fp64),
> >> >> EXT(ARB_sample_shading, true, false,
> >> >> ARB_sample_shading),
> >
Re: [Mesa-dev] [PATCH v3 06/29] glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)
Interesting... Does the actual hardware support double? (atleast for nv0)
Thank you!
On Sun, Feb 8, 2015 at 12:20 PM, Ilia Mirkin wrote:
> It all works fine on nvc0 and softpipe with my branch at
>
> https://github.com/imirkin/mesa/commits/fp64-4
>
> This branch also includes Dave's preliminary work on r600/cayman, not
> sure how far along it is, I believe it's still missing a few things.
> The nvc0 implementation needs a few more finishing touches for
> handling RCP and RSQ better (just adding a couple of steps of
> Newton-Raphson, since the hw only computes 32 bits of the 64-bit
> result).
>
>
> On Sun, Feb 8, 2015 at 12:04 PM, Aditya Avinash
> wrote:
> > Hi,
> > How far is glsl compiler working for fp64 shader?
> >
> > On Sun, Feb 8, 2015 at 4:00 AM, Ilia Mirkin
> wrote:
> >>
> >> From: Dave Airlie
> >>
> >> v2: add define bit (Tapani Pälli)
> >>
> >> Patch makes following Piglit tests pass:
> >>arb_gpu_shader_fp64/preprocessor/define.vert
> >>arb_gpu_shader_fp64/preprocessor/define.frag
> >>
> >> Reviewed-by: Ian Romanick
> >> Signed-off-by: Dave Airlie
> >> Reviewed-by: Matt Turner
> >> ---
> >> src/glsl/glcpp/glcpp-parse.y| 3 +++
> >> src/glsl/glsl_parser_extras.cpp | 1 +
> >> src/glsl/glsl_parser_extras.h | 2 ++
> >> src/glsl/standalone_scaffolding.cpp | 1 +
> >> 4 files changed, 7 insertions(+)
> >>
> >> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> >> index e5bebe5..c2f5223 100644
> >> --- a/src/glsl/glcpp/glcpp-parse.y
> >> +++ b/src/glsl/glcpp/glcpp-parse.y
> >> @@ -2445,6 +2445,9 @@
> >> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser,
> intmax_t
> >> versio
> >> if (extensions->ARB_gpu_shader5)
> >> add_builtin_define(parser, "GL_ARB_gpu_shader5", 1);
> >>
> >> + if (extensions->ARB_gpu_shader_fp64)
> >> + add_builtin_define(parser, "GL_ARB_gpu_shader_fp64",
> 1);
> >> +
> >> if (extensions->AMD_vertex_shader_layer)
> >> add_builtin_define(parser,
> "GL_AMD_vertex_shader_layer",
> >> 1);
> >>
> >> diff --git a/src/glsl/glsl_parser_extras.cpp
> >> b/src/glsl/glsl_parser_extras.cpp
> >> index ccdf031..cb19ce1 100644
> >> --- a/src/glsl/glsl_parser_extras.cpp
> >> +++ b/src/glsl/glsl_parser_extras.cpp
> >> @@ -527,6 +527,7 @@ static const _mesa_glsl_extension
> >> _mesa_glsl_supported_extensions[] = {
> >> EXT(ARB_fragment_coord_conventions, true, false,
> >> ARB_fragment_coord_conventions),
> >> EXT(ARB_fragment_layer_viewport,true, false,
> >> ARB_fragment_layer_viewport),
> >> EXT(ARB_gpu_shader5,true, false,
> >> ARB_gpu_shader5),
> >> + EXT(ARB_gpu_shader_fp64,true, false,
> >> ARB_gpu_shader_fp64),
> >> EXT(ARB_sample_shading, true, false,
> >> ARB_sample_shading),
> >> EXT(ARB_separate_shader_objects,true, false, dummy_true),
> >> EXT(ARB_shader_atomic_counters, true, false,
> >> ARB_shader_atomic_counters),
> >> diff --git a/src/glsl/glsl_parser_extras.h
> b/src/glsl/glsl_parser_extras.h
> >> index 843fdae..dafee4e 100644
> >> --- a/src/glsl/glsl_parser_extras.h
> >> +++ b/src/glsl/glsl_parser_extras.h
> >> @@ -414,6 +414,8 @@ struct _mesa_glsl_parse_state {
> >> bool ARB_fragment_layer_viewport_warn;
> >> bool ARB_gpu_shader5_enable;
> >> bool ARB_gpu_shader5_warn;
> >> + bool ARB_gpu_shader_fp64_enable;
> >> + bool ARB_gpu_shader_fp64_warn;
> >> bool ARB_sample_shading_enable;
> >> bool ARB_sample_shading_warn;
> >> bool ARB_separate_shader_objects_enable;
> >> diff --git a/src/glsl/standalone_scaffolding.cpp
> >> b/src/glsl/standalone_scaffolding.cpp
> >> index 67b0d0c..ad0d75b 100644
> >> --- a/src/glsl/standalone_scaffolding.cpp
> >> +++ b/src/glsl/standalone_scaffolding.cpp
> >> @@ -127,6 +127,7 @@ void initialize_context_to_defaults(struct
> gl_context
> >> *ctx, gl_api api)
> >> ctx->Extensions.ARB_fragment_coord_conventions = true;
> >> ctx->Extensions.ARB_fragment_layer_viewport = true;
> >> ctx->Extensions.ARB_gpu_shader5 = true;
> >> + ctx->Extensions.ARB_gpu_shader_fp64 = true;
> >> ctx->Extensions.ARB_sample_shading = true;
> >> ctx->Extensions.ARB_shader_bit_encoding = true;
> >> ctx->Extensions.ARB_shader_stencil_export = true;
> >> --
> >> 2.0.5
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
> >
> >
> > --
> > Regards,
> > Aditya Atluri,
> > USA.
> >
>
--
Regards,
*Aditya Atluri,*
*USA.*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 06/29] glsl: add ARB_gpu_shader_fp64 to the glsl extensions. (v2)
Hi,
How far is glsl compiler working for fp64 shader?
On Sun, Feb 8, 2015 at 4:00 AM, Ilia Mirkin wrote:
> From: Dave Airlie
>
> v2: add define bit (Tapani Pälli)
>
> Patch makes following Piglit tests pass:
>arb_gpu_shader_fp64/preprocessor/define.vert
>arb_gpu_shader_fp64/preprocessor/define.frag
>
> Reviewed-by: Ian Romanick
> Signed-off-by: Dave Airlie
> Reviewed-by: Matt Turner
> ---
> src/glsl/glcpp/glcpp-parse.y| 3 +++
> src/glsl/glsl_parser_extras.cpp | 1 +
> src/glsl/glsl_parser_extras.h | 2 ++
> src/glsl/standalone_scaffolding.cpp | 1 +
> 4 files changed, 7 insertions(+)
>
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index e5bebe5..c2f5223 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -2445,6 +2445,9 @@
> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser, intmax_t
> versio
> if (extensions->ARB_gpu_shader5)
> add_builtin_define(parser, "GL_ARB_gpu_shader5", 1);
>
> + if (extensions->ARB_gpu_shader_fp64)
> + add_builtin_define(parser, "GL_ARB_gpu_shader_fp64", 1);
> +
> if (extensions->AMD_vertex_shader_layer)
> add_builtin_define(parser, "GL_AMD_vertex_shader_layer",
> 1);
>
> diff --git a/src/glsl/glsl_parser_extras.cpp
> b/src/glsl/glsl_parser_extras.cpp
> index ccdf031..cb19ce1 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -527,6 +527,7 @@ static const _mesa_glsl_extension
> _mesa_glsl_supported_extensions[] = {
> EXT(ARB_fragment_coord_conventions, true, false,
> ARB_fragment_coord_conventions),
> EXT(ARB_fragment_layer_viewport,true, false,
> ARB_fragment_layer_viewport),
> EXT(ARB_gpu_shader5,true, false, ARB_gpu_shader5),
> + EXT(ARB_gpu_shader_fp64,true, false,
> ARB_gpu_shader_fp64),
> EXT(ARB_sample_shading, true, false,
> ARB_sample_shading),
> EXT(ARB_separate_shader_objects,true, false, dummy_true),
> EXT(ARB_shader_atomic_counters, true, false,
> ARB_shader_atomic_counters),
> diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
> index 843fdae..dafee4e 100644
> --- a/src/glsl/glsl_parser_extras.h
> +++ b/src/glsl/glsl_parser_extras.h
> @@ -414,6 +414,8 @@ struct _mesa_glsl_parse_state {
> bool ARB_fragment_layer_viewport_warn;
> bool ARB_gpu_shader5_enable;
> bool ARB_gpu_shader5_warn;
> + bool ARB_gpu_shader_fp64_enable;
> + bool ARB_gpu_shader_fp64_warn;
> bool ARB_sample_shading_enable;
> bool ARB_sample_shading_warn;
> bool ARB_separate_shader_objects_enable;
> diff --git a/src/glsl/standalone_scaffolding.cpp
> b/src/glsl/standalone_scaffolding.cpp
> index 67b0d0c..ad0d75b 100644
> --- a/src/glsl/standalone_scaffolding.cpp
> +++ b/src/glsl/standalone_scaffolding.cpp
> @@ -127,6 +127,7 @@ void initialize_context_to_defaults(struct gl_context
> *ctx, gl_api api)
> ctx->Extensions.ARB_fragment_coord_conventions = true;
> ctx->Extensions.ARB_fragment_layer_viewport = true;
> ctx->Extensions.ARB_gpu_shader5 = true;
> + ctx->Extensions.ARB_gpu_shader_fp64 = true;
> ctx->Extensions.ARB_sample_shading = true;
> ctx->Extensions.ARB_shader_bit_encoding = true;
> ctx->Extensions.ARB_shader_stencil_export = true;
> --
> 2.0.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
Regards,
*Aditya Atluri,*
*USA.*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: remove set_shader_resources, add set_shader_buffers for untyped buffers
Thank you! On Wednesday, January 7, 2015, Marek Olšák wrote: > On Wed, Jan 7, 2015 at 2:42 PM, Aditya Avinash > wrote: > > Hi, > > Sounds great but, do you think a separate buffer pipe is required for > this? > > Changing Constant buffer to a generic buffer (with alu+load+store) can > help. > > No, constant buffers should remain unchanged. > > > > > What about for R600? Do we have to add > > > > r600_init_atom(rctx, &rctx->shaderbuf_state[PIPE_SHADER_VERTEX].atom, > id++, > > r600_emit_vs_shader_buffers, 0); > > > > to backend? Will this be specific to Atomics? > > No, atomic buffers should be set in the exact same way as colorbuffers > on r600 except that the RAT bit should be set. Search the r600g driver > for "RAT(1)". I think it supports them already. The shader > instructions for accessing such buffers begin with "MEM_RAT". > > Marek > > > > > Thank you!! > > > > On Wed, Jan 7, 2015 at 4:56 AM, Marek Olšák > wrote: > >> > >> From: Marek Olšák > > >> > >> set_shader_resources is unused. > >> > >> set_shader_buffers should support shader atomic counter buffers and > shader > >> storage buffers from OpenGL. > >> > >> The plan is to use slots 0..15 for atomic counters and slots 16..31 > >> for storage buffers. Atomic counters are planned to be supported first. > >> > >> This doesn't add any interface for images. The documentation is added > >> for future reference. > >> --- > >> > >> This is the interface only. I don't plan to do anything else for now. > >> Comments welcome. > >> > >> src/gallium/docs/source/context.rst | 16 > >> src/gallium/docs/source/screen.rst | 4 ++-- > >> src/gallium/drivers/galahad/glhd_context.c | 2 +- > >> src/gallium/drivers/ilo/ilo_state.c | 2 +- > >> src/gallium/drivers/nouveau/nouveau_buffer.c| 2 +- > >> src/gallium/drivers/nouveau/nouveau_screen.c| 2 +- > >> src/gallium/drivers/nouveau/nv50/nv50_formats.c | 2 +- > >> src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 2 +- > >> src/gallium/include/pipe/p_context.h| 20 > +++- > >> src/gallium/include/pipe/p_defines.h| 2 +- > >> src/gallium/include/pipe/p_state.h | 10 ++ > >> 11 files changed, 38 insertions(+), 26 deletions(-) > >> > >> diff --git a/src/gallium/docs/source/context.rst > >> b/src/gallium/docs/source/context.rst > >> index 5861f46..73fd35f 100644 > >> --- a/src/gallium/docs/source/context.rst > >> +++ b/src/gallium/docs/source/context.rst > >> @@ -126,14 +126,14 @@ from a shader without an associated sampler. This > >> means that they > >> have no support for floating point coordinates, address wrap modes or > >> filtering. > >> > >> -Shader resources are specified for all the shader stages at once using > >> -the ``set_shader_resources`` method. When binding texture resources, > >> -the ``level``, ``first_layer`` and ``last_layer`` pipe_surface fields > >> -specify the mipmap level and the range of layers the texture will be > >> -constrained to. In the case of buffers, ``first_element`` and > >> -``last_element`` specify the range within the buffer that will be used > >> -by the shader resource. Writes to a shader resource are only allowed > >> -when the ``writable`` flag is set. > >> +There are 2 types of shader resources: buffers and images. > >> + > >> +Buffers are specified using the ``set_shader_buffers`` method. > >> + > >> +Images are specified using the ``set_shader_images`` method. When > binding > >> +images, the ``level``, ``first_layer`` and ``last_layer`` > pipe_image_view > >> +fields specify the mipmap level and the range of layers the image will > be > >> +constrained to. > >> > >> Surfaces > >> > >> diff --git a/src/gallium/docs/source/screen.rst > >> b/src/gallium/docs/source/screen.rst > >> index 55d114c..c81ad66 100644 > >> --- a/src/gallium/docs/source/screen.rst > >> +++ b/src/gallium/docs/source/screen.rst > >> @@ -403,8 +403,8 @@ resources might be created and handled quite > >> differently. > >>process. > >> * ``PIPE_BIND_GLOBAL``: A buffer that can be mapped into the global > >>address space of a comp
Re: [Mesa-dev] [PATCH] gallium: remove set_shader_resources, add set_shader_buffers for untyped buffers
Oh. So, we get better performance if we use atomic counters as buffers rather than textures (images) [manipulating views are expensive]. Am I right? On Wed, Jan 7, 2015 at 8:52 AM, Marek Olšák wrote: > On Wed, Jan 7, 2015 at 3:44 PM, Aditya Avinash > wrote: > > > > > > On Wed, Jan 7, 2015 at 4:56 AM, Marek Olšák wrote: > >> > >> From: Marek Olšák > >> > >> set_shader_resources is unused. > >> > >> set_shader_buffers should support shader atomic counter buffers and > shader > >> storage buffers from OpenGL. > >> > >> The plan is to use slots 0..15 for atomic counters and slots 16..31 > >> for storage buffers. Atomic counters are planned to be supported first. > >> > >> This doesn't add any interface for images. The documentation is added > >> for future reference. > >> --- > >> > >> This is the interface only. I don't plan to do anything else for now. > >> Comments welcome. > >> > >> src/gallium/docs/source/context.rst | 16 > >> src/gallium/docs/source/screen.rst | 4 ++-- > >> src/gallium/drivers/galahad/glhd_context.c | 2 +- > >> src/gallium/drivers/ilo/ilo_state.c | 2 +- > >> src/gallium/drivers/nouveau/nouveau_buffer.c| 2 +- > >> src/gallium/drivers/nouveau/nouveau_screen.c| 2 +- > >> src/gallium/drivers/nouveau/nv50/nv50_formats.c | 2 +- > >> src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 2 +- > >> src/gallium/include/pipe/p_context.h| 20 > +++- > >> src/gallium/include/pipe/p_defines.h| 2 +- > >> src/gallium/include/pipe/p_state.h | 10 ++ > >> 11 files changed, 38 insertions(+), 26 deletions(-) > >> > >> diff --git a/src/gallium/docs/source/context.rst > >> b/src/gallium/docs/source/context.rst > >> index 5861f46..73fd35f 100644 > >> --- a/src/gallium/docs/source/context.rst > >> +++ b/src/gallium/docs/source/context.rst > >> @@ -126,14 +126,14 @@ from a shader without an associated sampler. This > >> means that they > >> have no support for floating point coordinates, address wrap modes or > >> filtering. > >> > >> -Shader resources are specified for all the shader stages at once using > >> -the ``set_shader_resources`` method. When binding texture resources, > >> -the ``level``, ``first_layer`` and ``last_layer`` pipe_surface fields > >> -specify the mipmap level and the range of layers the texture will be > >> -constrained to. In the case of buffers, ``first_element`` and > >> -``last_element`` specify the range within the buffer that will be used > >> -by the shader resource. Writes to a shader resource are only allowed > >> -when the ``writable`` flag is set. > >> +There are 2 types of shader resources: buffers and images. > >> + > >> +Buffers are specified using the ``set_shader_buffers`` method. > >> + > >> +Images are specified using the ``set_shader_images`` method. When > binding > >> +images, the ``level``, ``first_layer`` and ``last_layer`` > pipe_image_view > >> +fields specify the mipmap level and the range of layers the image will > be > >> +constrained to. > >> > >> Surfaces > >> > > > > > > set_shader_images are not defined in this patch. > > Will it look similar to pipe_surface or pipe_sampler_view? > > There will be a separate view for images if this is approved. > > Marek > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: remove set_shader_resources, add set_shader_buffers for untyped buffers
On Wed, Jan 7, 2015 at 4:56 AM, Marek Olšák wrote: > From: Marek Olšák > > set_shader_resources is unused. > > set_shader_buffers should support shader atomic counter buffers and shader > storage buffers from OpenGL. > > The plan is to use slots 0..15 for atomic counters and slots 16..31 > for storage buffers. Atomic counters are planned to be supported first. > > This doesn't add any interface for images. The documentation is added > for future reference. > --- > > This is the interface only. I don't plan to do anything else for now. > Comments welcome. > > src/gallium/docs/source/context.rst | 16 > src/gallium/docs/source/screen.rst | 4 ++-- > src/gallium/drivers/galahad/glhd_context.c | 2 +- > src/gallium/drivers/ilo/ilo_state.c | 2 +- > src/gallium/drivers/nouveau/nouveau_buffer.c| 2 +- > src/gallium/drivers/nouveau/nouveau_screen.c| 2 +- > src/gallium/drivers/nouveau/nv50/nv50_formats.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 2 +- > src/gallium/include/pipe/p_context.h| 20 +++- > src/gallium/include/pipe/p_defines.h| 2 +- > src/gallium/include/pipe/p_state.h | 10 ++ > 11 files changed, 38 insertions(+), 26 deletions(-) > > diff --git a/src/gallium/docs/source/context.rst > b/src/gallium/docs/source/context.rst > index 5861f46..73fd35f 100644 > --- a/src/gallium/docs/source/context.rst > +++ b/src/gallium/docs/source/context.rst > @@ -126,14 +126,14 @@ from a shader without an associated sampler. This > means that they > have no support for floating point coordinates, address wrap modes or > filtering. > > -Shader resources are specified for all the shader stages at once using > -the ``set_shader_resources`` method. When binding texture resources, > -the ``level``, ``first_layer`` and ``last_layer`` pipe_surface fields > -specify the mipmap level and the range of layers the texture will be > -constrained to. In the case of buffers, ``first_element`` and > -``last_element`` specify the range within the buffer that will be used > -by the shader resource. Writes to a shader resource are only allowed > -when the ``writable`` flag is set. > +There are 2 types of shader resources: buffers and images. > + > +Buffers are specified using the ``set_shader_buffers`` method. > + > +Images are specified using the ``set_shader_images`` method. When binding > +images, the ``level``, ``first_layer`` and ``last_layer`` pipe_image_view > +fields specify the mipmap level and the range of layers the image will be > +constrained to. > > Surfaces > > set_shader_images are not defined in this patch. Will it look similar to pipe_surface or pipe_sampler_view? > diff --git a/src/gallium/docs/source/screen.rst > b/src/gallium/docs/source/screen.rst > index 55d114c..c81ad66 100644 > --- a/src/gallium/docs/source/screen.rst > +++ b/src/gallium/docs/source/screen.rst > @@ -403,8 +403,8 @@ resources might be created and handled quite > differently. >process. > * ``PIPE_BIND_GLOBAL``: A buffer that can be mapped into the global >address space of a compute program. > -* ``PIPE_BIND_SHADER_RESOURCE``: A buffer or texture that can be > - bound to the graphics pipeline as a shader resource. > +* ``PIPE_BIND_SHADER_BUFFER``: A buffer that can be bound to a shader > where > + it should support reads, writes, and atomics. > * ``PIPE_BIND_COMPUTE_RESOURCE``: A buffer or texture that can be >bound to the compute program as a shader resource. > * ``PIPE_BIND_COMMAND_ARGS_BUFFER``: A buffer that may be sourced by the > diff --git a/src/gallium/drivers/galahad/glhd_context.c > b/src/gallium/drivers/galahad/glhd_context.c > index 37ea170..383d76c 100644 > --- a/src/gallium/drivers/galahad/glhd_context.c > +++ b/src/gallium/drivers/galahad/glhd_context.c > @@ -1017,7 +1017,7 @@ galahad_context_create(struct pipe_screen *_screen, > struct pipe_context *pipe) > GLHD_PIPE_INIT(set_scissor_states); > GLHD_PIPE_INIT(set_viewport_states); > GLHD_PIPE_INIT(set_sampler_views); > - //GLHD_PIPE_INIT(set_shader_resources); > + //GLHD_PIPE_INIT(set_shader_buffers); > GLHD_PIPE_INIT(set_vertex_buffers); > GLHD_PIPE_INIT(set_index_buffer); > GLHD_PIPE_INIT(create_stream_output_target); > diff --git a/src/gallium/drivers/ilo/ilo_state.c > b/src/gallium/drivers/ilo/ilo_state.c > index b852f9f..09209ec 100644 > --- a/src/gallium/drivers/ilo/ilo_state.c > +++ b/src/gallium/drivers/ilo/ilo_state.c > @@ -1267,7 +1267,7 @@ ilo_init_state_functions(struct ilo_context *ilo) > ilo->base.set_scissor_states = ilo_set_scissor_states; > ilo->base.set_viewport_states = ilo_set_viewport_states; > ilo->base.set_sampler_views = ilo_set_sampler_views; > - ilo->base.set_shader_resources = ilo_set_shader_resources; > + //ilo->base.set_shader_resources = ilo_set_shader_resources; > ilo->base.set_vertex_buffers = ilo_set_vertex_buffe
Re: [Mesa-dev] [PATCH] gallium: remove set_shader_resources, add set_shader_buffers for untyped buffers
Hi, Sounds great but, do you think a separate buffer pipe is required for this? Changing Constant buffer to a generic buffer (with alu+load+store) can help. What about for R600? Do we have to add r600_init_atom(rctx, &rctx->shaderbuf_state[PIPE_SHADER_VERTEX].atom, id++, r600_emit_vs_shader_buffers, 0); to backend? Will this be specific to Atomics? Thank you!! On Wed, Jan 7, 2015 at 4:56 AM, Marek Olšák wrote: > From: Marek Olšák > > set_shader_resources is unused. > > set_shader_buffers should support shader atomic counter buffers and shader > storage buffers from OpenGL. > > The plan is to use slots 0..15 for atomic counters and slots 16..31 > for storage buffers. Atomic counters are planned to be supported first. > > This doesn't add any interface for images. The documentation is added > for future reference. > --- > > This is the interface only. I don't plan to do anything else for now. > Comments welcome. > > src/gallium/docs/source/context.rst | 16 > src/gallium/docs/source/screen.rst | 4 ++-- > src/gallium/drivers/galahad/glhd_context.c | 2 +- > src/gallium/drivers/ilo/ilo_state.c | 2 +- > src/gallium/drivers/nouveau/nouveau_buffer.c| 2 +- > src/gallium/drivers/nouveau/nouveau_screen.c| 2 +- > src/gallium/drivers/nouveau/nv50/nv50_formats.c | 2 +- > src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 2 +- > src/gallium/include/pipe/p_context.h| 20 +++- > src/gallium/include/pipe/p_defines.h| 2 +- > src/gallium/include/pipe/p_state.h | 10 ++ > 11 files changed, 38 insertions(+), 26 deletions(-) > > diff --git a/src/gallium/docs/source/context.rst > b/src/gallium/docs/source/context.rst > index 5861f46..73fd35f 100644 > --- a/src/gallium/docs/source/context.rst > +++ b/src/gallium/docs/source/context.rst > @@ -126,14 +126,14 @@ from a shader without an associated sampler. This > means that they > have no support for floating point coordinates, address wrap modes or > filtering. > > -Shader resources are specified for all the shader stages at once using > -the ``set_shader_resources`` method. When binding texture resources, > -the ``level``, ``first_layer`` and ``last_layer`` pipe_surface fields > -specify the mipmap level and the range of layers the texture will be > -constrained to. In the case of buffers, ``first_element`` and > -``last_element`` specify the range within the buffer that will be used > -by the shader resource. Writes to a shader resource are only allowed > -when the ``writable`` flag is set. > +There are 2 types of shader resources: buffers and images. > + > +Buffers are specified using the ``set_shader_buffers`` method. > + > +Images are specified using the ``set_shader_images`` method. When binding > +images, the ``level``, ``first_layer`` and ``last_layer`` pipe_image_view > +fields specify the mipmap level and the range of layers the image will be > +constrained to. > > Surfaces > > diff --git a/src/gallium/docs/source/screen.rst > b/src/gallium/docs/source/screen.rst > index 55d114c..c81ad66 100644 > --- a/src/gallium/docs/source/screen.rst > +++ b/src/gallium/docs/source/screen.rst > @@ -403,8 +403,8 @@ resources might be created and handled quite > differently. >process. > * ``PIPE_BIND_GLOBAL``: A buffer that can be mapped into the global >address space of a compute program. > -* ``PIPE_BIND_SHADER_RESOURCE``: A buffer or texture that can be > - bound to the graphics pipeline as a shader resource. > +* ``PIPE_BIND_SHADER_BUFFER``: A buffer that can be bound to a shader > where > + it should support reads, writes, and atomics. > * ``PIPE_BIND_COMPUTE_RESOURCE``: A buffer or texture that can be >bound to the compute program as a shader resource. > * ``PIPE_BIND_COMMAND_ARGS_BUFFER``: A buffer that may be sourced by the > diff --git a/src/gallium/drivers/galahad/glhd_context.c > b/src/gallium/drivers/galahad/glhd_context.c > index 37ea170..383d76c 100644 > --- a/src/gallium/drivers/galahad/glhd_context.c > +++ b/src/gallium/drivers/galahad/glhd_context.c > @@ -1017,7 +1017,7 @@ galahad_context_create(struct pipe_screen *_screen, > struct pipe_context *pipe) > GLHD_PIPE_INIT(set_scissor_states); > GLHD_PIPE_INIT(set_viewport_states); > GLHD_PIPE_INIT(set_sampler_views); > - //GLHD_PIPE_INIT(set_shader_resources); > + //GLHD_PIPE_INIT(set_shader_buffers); > GLHD_PIPE_INIT(set_vertex_buffers); > GLHD_PIPE_INIT(set_index_buffer); > GLHD_PIPE_INIT(create_stream_output_target); > diff --git a/src/gallium/drivers/ilo/ilo_state.c > b/src/gallium/drivers/ilo/ilo_state.c > index b852f9f..09209ec 100644 > --- a/src/gallium/drivers/ilo/ilo_state.c > +++ b/src/gallium/drivers/ilo/ilo_state.c > @@ -1267,7 +1267,7 @@ ilo_init_state_functions(struct ilo_context *ilo) > ilo->base.set_scissor_states = ilo_set_scissor_states; > ilo->base.set_viewport_states = ilo_set_viewport_s
Re: [Mesa-dev] [PATCH 1/2] gallium/include/pipe: Added interface for atomic counter buffers in pipe
On Tue, Jan 6, 2015 at 4:23 PM, Marek Olšák wrote: > Having a different view type for writable shader resources sounds good. > > An alternative solution would be to have separate functions for images > and buffers: > > - set_image_views - image views only, pipe_image_view should look > similar to pipe_surface > > - set_shader_buffers - buffers only, untyped, no views, each slot has > only 3 parameters: resource, offset, size > I am not expert on this but, with my experience reading the code. I think using a generic one with flags set in it could be better. Using "union" can also be a better design. As textures and buffers can be used as resources from shaders, using a generic one and setting flags can be useful. > That would be even better from the radeonsi design point of view, and > it would avoid creating a useless view for writable buffers, which are > always untyped in GL. > > Marek > > On Tue, Jan 6, 2015 at 10:09 PM, Roland Scheidegger > wrote: > > Actually initially pipe_surface really was for "traditional" render > > surface. There were even stand-alone surfaces (i.e. not based on > > resources) for the non-fbo (system window) surfaces - this is why the > > width/height fields are actually still in there in a pipe_surface (yes > > with a XXX comment)... > > So, the functionality was really all restricted to GL2 / d3d9 level, > > hence it didn't really make a difference how you interpreted it, as > > there weren't any different bind points. > > I'm not sure if we really need a different view for uavs or whatever you > > want to call them in gallium. d3d does that but for instance we didn't > > do different views for depth stencil / rt neither as it seemed quite > > redundant (but nonetheless, create_surface was indeed intended to serve > > the role of the create depth stencil and render target views, at least > > once we cleaned it up to really rely on resources). If it can be reused > > for uavs in a reasonably clean way that's ok - as I said the biggest > > problem I see is that when you create the view the driver won't know for > > which bind point this view is and it must be able to bind the same view > > to several different bind points later. It is, however, probably > > suboptimal if you'd have a driver which needs things closer to d3d > > semantics (as we do in the svga driver) - at least if you'd have > > specified different bind points in the resource the driver is going to > > need to generate multiple views on its own internally. In that way it > > may be cleaner if each different bind point would have its own view. > > > > Roland > > > > > > > > Am 06.01.2015 um 20:14 schrieb Ilia Mirkin: > >> Ah, OK. I was interpreting sampler view as "all the things you need to > >> be able to sample from a resource", and surface as "all the things you > >> need to know where to write in a resource", including a render target. > >> But you guys have all been playing this game for much much longer than > >> me... > >> > >> On Tue, Jan 6, 2015 at 1:37 PM, Marek Olšák wrote: > >>> I thought pipe_surface was a render target view. > >>> > >>> From the r600 point of view, writable resources are pretty much > >>> "colorbuffers", because they share slots with colorbuffers and are set > >>> up exactly like colorbuffers. So pipe_surface maps well to r600, and > >>> using set_framebuffer_state for setting UAVs would be perfect for that > >>> hardware, but it would be ugly. > >>> > >>> From the radeonsi point of view, writable resources are no different > >>> from textures and texture buffers. So pipe_sampler_view maps well to > >>> radeonsi. > >>> > >>> Marek > >>> > >>> On Tue, Jan 6, 2015 at 7:17 PM, Ilia Mirkin > wrote: > I thought that a surface was basically a writable view into a > resource. What does sampler view have that surface doesn't (that > matters)? The only thing I can think of is levels, but does anything > actually support multi-level stuff? (ARB_shader_image_load_store > doesn't seem to.) > > On Tue, Jan 6, 2015 at 12:54 PM, Marek Olšák > wrote: > > I would just rename pipe_sampler_view to pipe_resource_view. I don't > > think "pipe_sampler_view" has a lot to do with samplers. It's just a > > universal view into textures and yes, buffers too. Of course, some > > fields don't apply to certain types and use cases. > > > > OMSetRenderTargetsAndUnorderedAccessViews looks like a design fail. > It > > exactly matches Evergreen/Cayman design, which is now deprecated. > > Evergreen shares UAV slots with colorbuffers. There are 12 slots, the > > first 8 can be colorbuffers, those that are unused can be UAVs, so > you > > have at least 4. If you bind only one colorbuffer, you can bind 11 > > UAVs, etc. The other problem with this design is that UAVs can only > be > > used in the pixel shader. It would be a bad idea to follow this > design > > precisely in Gallium. We should have something more generic and let
Re: [Mesa-dev] [PATCH 1/2] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Hi,
I lost this mail in the mail box.
I am sorry about patch related to pipe. My work is based on Ilia Mirkin
pipe commits. As per my previous mail, you can ignore pipe patch.
My current work is related to R600 backend.
On Tue, Jan 6, 2015 at 8:54 AM, Jose Fonseca wrote:
> Do we really need a new pipe_context::set_counter_buffer method?
> Shouldn't this case be covered by pipe_context::set_shader_resources ?
>
> If we really need new method, I'd like we have better names for them, so
> we can clearly distinguish them.
>
I wanted to know whether this is exactly the way or it should be redone.
> IIUC GL_ARB_shader_atomic_counters correctly, this roughly matches D3D11s
> "unordered access views" [1], though D3D11's UAVs can by typed [2], or raw
> [3].
>
> Also, are counter buffers in user memory really supported? I can't spot
> any mention of that in GL_ARB_shader_atomic_counters.
>
> I think that rather than mimicking pipe_constant_buffer, this feature
> should more closely to sampler views.
>
>
I'll check it.
>
> I confess I'm not familiar with counter buffers / UAVs, but I think this
> needs a bit more thought to avoid being completely redone in the medium
> term.
>
>
> Jose
>
>
> [1] http://msdn.microsoft.com/en-gb/library/windows/desktop/
> ff476335.aspx#Unordered_Access
> [2] http://msdn.microsoft.com/en-gb/library/windows/desktop/ff476258.aspx
> [3] http://msdn.microsoft.com/en-gb/library/windows/desktop/
> ff476900.aspx#Raw_Buffer_Views
>
>
> On 04/01/15 21:44, adityaatluri wrote:
>
>> ---
>> src/gallium/include/pipe/p_context.h | 5 +
>> src/gallium/include/pipe/p_defines.h | 7 ++-
>> src/gallium/include/pipe/p_state.h | 10 ++
>> 3 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index af5674f..bf3be31 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -44,6 +44,7 @@ struct pipe_blit_info;
>> struct pipe_box;
>> struct pipe_clip_state;
>> struct pipe_constant_buffer;
>> +struct pipe_counter_buffer;
>> struct pipe_depth_stencil_alpha_state;
>> struct pipe_draw_info;
>> struct pipe_fence_handle;
>> @@ -201,6 +202,10 @@ struct pipe_context {
>> uint shader, uint index,
>> struct pipe_constant_buffer *buf );
>>
>> + void (*set_counter_buffer)( struct pipe_context *,
>> + uint shader, uint index,
>> + struct pipe_counter_buffer *buf );
>> +
>>
>
>
>
>
> void (*set_framebuffer_state)( struct pipe_context *,
>> const struct pipe_framebuffer_state *
>> );
>>
>> diff --git a/src/gallium/include/pipe/p_defines.h
>> b/src/gallium/include/pipe/p_defines.h
>> index 8c4e415..717ab6a 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -341,6 +341,7 @@ enum pipe_flush_flags {
>> #define PIPE_BIND_VERTEX_BUFFER(1 << 4) /* set_vertex_buffers */
>> #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */
>> #define PIPE_BIND_CONSTANT_BUFFER (1 << 6) /* set_constant_buffer
>> */
>> +#define PIPE_BIND_COUNTER_BUFFER (1 << 7) /* set_counter_buffer */
>> #define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer */
>> #define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* transfer_map */
>> #define PIPE_BIND_TRANSFER_READ(1 << 10) /* transfer_map */
>> @@ -572,6 +573,8 @@ enum pipe_cap {
>> PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109,
>> PIPE_CAP_SAMPLER_VIEW_TARGET = 110,
>> PIPE_CAP_CLIP_HALFZ = 111,
>> + PIPE_CAP_USER_COUNTER_BUFFERS = 112,
>> + PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113,
>> };
>>
>> #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
>> @@ -631,7 +634,9 @@ enum pipe_shader_cap
>> PIPE_SHADER_CAP_PREFERRED_IR,
>> PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED,
>> PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS,
>> - PIPE_SHADER_CAP_DOUBLES
>> + PIPE_SHADER_CAP_DOUBLES,
>> + PIPE_SHADER_CAP_MAX_COUNTER_BUFFER_SIZE,
>> + PIPE_SHADER_CAP_MAX_COUNTER_BUFFERS
>> };
>>
>> /**
>> diff --git a/src/gallium/include/pipe/p_state.h
>> b/src/gallium/include/pipe/p_state.h
>> index 43bc48b..49fae5d 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -57,6 +57,7 @@ extern "C" {
>> #define PIPE_MAX_CLIP_PLANES 8
>> #define PIPE_MAX_COLOR_BUFS8
>> #define PIPE_MAX_CONSTANT_BUFFERS 32
>> +#define PIPE_MAX_COUNTER_BUFFERS 32
>> #define PIPE_MAX_SAMPLERS 16
>> #define PIPE_MAX_SHADER_INPUTS32
>> #define PIPE_MAX_SHADER_OUTPUTS 48 /* 32 GENERICs + POS, PSIZE, FOG,
>> etc. */
>> @@ -462,6 +463,15 @@ struct pipe_constant_buffer {
>> const void *user_buffer; /**< pointer to a user buffer if buffer ==
>> NULL */
>> };
>>
>
Re: [Mesa-dev] [PATCH 1/2] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Hi,
About this patch:
1. It is not tested. I'll test it after 12th.
2. It implements atomic buffers as a surface which can be reused for
ARB_shader_image_load_store
3. You can ignore the first patch.
My questions:
1. What does R_028AC0_ALU_ATOM_CACHE_GS_0 represent?
2. What determines the values 160, 336 and 0 in
r600_emit_vs,gs,ps_atomic,constant_buffers();?
3. What does these macros represent? What are they used for?
#define R600_UCP_CONST_BUFFERR600_MAX_USER_CONST_BUFFERS
#define R600_TXQ_CONST_BUFFERR600_MAX_USER_CONST_BUFFERS + 1
#define R600_BUFFER_INFO_CONST_BUFFERR600_MAX_USER_CONST_BUFFERS + 2
#define R600_GS_RING_CONST_BUFFERR600_MAX_USER_CONST_BUFFERS + 3
#define R600_MAX_CONST_BUFFER_SIZE(4096 * sizeof(float[4])) // It
is self-explanatory here.
4. What is the function of R600_CONTEXT_INV_ATOM_CACHE?
5. Does my implementation make sense?
Thank you!!
On Sun, Jan 4, 2015 at 3:44 PM, adityaatluri
wrote:
> ---
> src/gallium/include/pipe/p_context.h | 5 +
> src/gallium/include/pipe/p_defines.h | 7 ++-
> src/gallium/include/pipe/p_state.h | 10 ++
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index af5674f..bf3be31 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -44,6 +44,7 @@ struct pipe_blit_info;
> struct pipe_box;
> struct pipe_clip_state;
> struct pipe_constant_buffer;
> +struct pipe_counter_buffer;
> struct pipe_depth_stencil_alpha_state;
> struct pipe_draw_info;
> struct pipe_fence_handle;
> @@ -201,6 +202,10 @@ struct pipe_context {
> uint shader, uint index,
> struct pipe_constant_buffer *buf );
>
> + void (*set_counter_buffer)( struct pipe_context *,
> + uint shader, uint index,
> + struct pipe_counter_buffer *buf );
> +
> void (*set_framebuffer_state)( struct pipe_context *,
>const struct pipe_framebuffer_state * );
>
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index 8c4e415..717ab6a 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -341,6 +341,7 @@ enum pipe_flush_flags {
> #define PIPE_BIND_VERTEX_BUFFER(1 << 4) /* set_vertex_buffers */
> #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */
> #define PIPE_BIND_CONSTANT_BUFFER (1 << 6) /* set_constant_buffer */
> +#define PIPE_BIND_COUNTER_BUFFER (1 << 7) /* set_counter_buffer */
> #define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer */
> #define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* transfer_map */
> #define PIPE_BIND_TRANSFER_READ(1 << 10) /* transfer_map */
> @@ -572,6 +573,8 @@ enum pipe_cap {
> PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109,
> PIPE_CAP_SAMPLER_VIEW_TARGET = 110,
> PIPE_CAP_CLIP_HALFZ = 111,
> + PIPE_CAP_USER_COUNTER_BUFFERS = 112,
> + PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113,
> };
>
> #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
> @@ -631,7 +634,9 @@ enum pipe_shader_cap
> PIPE_SHADER_CAP_PREFERRED_IR,
> PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED,
> PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS,
> - PIPE_SHADER_CAP_DOUBLES
> + PIPE_SHADER_CAP_DOUBLES,
> + PIPE_SHADER_CAP_MAX_COUNTER_BUFFER_SIZE,
> + PIPE_SHADER_CAP_MAX_COUNTER_BUFFERS
> };
>
> /**
> diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> index 43bc48b..49fae5d 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -57,6 +57,7 @@ extern "C" {
> #define PIPE_MAX_CLIP_PLANES 8
> #define PIPE_MAX_COLOR_BUFS8
> #define PIPE_MAX_CONSTANT_BUFFERS 32
> +#define PIPE_MAX_COUNTER_BUFFERS 32
> #define PIPE_MAX_SAMPLERS 16
> #define PIPE_MAX_SHADER_INPUTS32
> #define PIPE_MAX_SHADER_OUTPUTS 48 /* 32 GENERICs + POS, PSIZE, FOG,
> etc. */
> @@ -462,6 +463,15 @@ struct pipe_constant_buffer {
> const void *user_buffer; /**< pointer to a user buffer if buffer ==
> NULL */
> };
>
> +/**
> + * A Counter buffer. A new buffer is set everytime a variable with
> + * atomic_uint is defined.
> + */
> +struct pipe_counter_buffer{
> + struct pipe_resource *buffer; /**< The actual buffer */
> + unsigned buffer_offset; /**< The offset to start of data in buffer in
> bytes */
> + const void *user_buffer; /**< The buffer which is created by the
> compiler */
> +};
>
> /**
> * A stream output target. The structure specifies the range vertices can
> --
> 1.9.1
>
>
> From c80ca0e4704b8fc325e109d1770f6c4900d14cec Mon Sep 17 00:00:00 2001
> From: adityaatluri
> Date: Sun, 4 Jan 2015 16:37:43 -0500
> Subject: [PATCH 2/2] drivers/r600: added atomic buffer
[Mesa-dev] R600 atomics integration
Hi, I am trying to integrate atomic counters to Mesa. I was able to do until pipes (with the help of Marek and Ilia). How to integrate them to R600? Thank you! -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Hi,
I agree with the solution. Considering "images" as "buffers" or "buffers"
as "images" (as they are operated inside shaders but not texture units)
makes sense. I think we can make atomic buffers as a part of
ARB_shader_image_load_store. Because, images are 2D array of buffers with
atomic operations run on them.
You have mentioned in our previous conversation about the un-necessity of
store. The spec for ARB_shader_image_load_store says imageStore(). If we
are implementing the same for atomics, then we have to use store for it too.
Thank you!!
On Mon, Nov 17, 2014 at 11:28 AM, Ilia Mirkin wrote:
> Because shader resources were already specified as pipe_surfaces (in
> the existing, albeit presently unused API). A pipe_surface is a
> wrapper around a resource that specifies what "view" of the resource
> should be writable, and attaches an optional format to that resource.
> Normally pipe_surfaces are used for render targets, but it applies
> just as well here. It applies especially well with a view towards
> ARB_shader_image_load_store.
>
> It's conceivable to make a totally separate thing for atomic buffers,
> but there's no good reason to -- they will have to be handled in
> essentially the same way as regular "image" surfaces will for
> ARB_shader_image_load_store.
>
> Cheers,
>
> -ilia
>
> On Mon, Nov 17, 2014 at 11:19 AM, Aditya Avinash
> wrote:
> > Hi,
> > I am having difficulty in understanding why you implemented pipe_surface
> in
> > st_atom_atomicbuf.c.
> >
> > On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash <
> adityaavina...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> On Sunday, November 16, 2014, Ilia Mirkin wrote:
> >>>
> >>> The direction I went in was by adapting the shader resources interface
> >>> for this. I believe it will be possible to use for
> >>> shader_image_load_store as well.
> >>
> >>
> >> I asked some questions on mailing list about the implementation. I took
> >> the same path as uniform buffers. But, I realized that it's not
> efficient to
> >> do that.
> >>
> >>>
> >>> See https://github.com/imirkin/mesa/commits/atomic
> >>>
> >>
> >> The commits are similar to my previous patch. I was doing atomics
> similar
> >> to uniform buffers, Now I was changing cso_context.
> >>
> >>>
> >>> I believe that makes a lot more sense than creating a special counter
> >>> buffer type only to be used for this. pipe_surface has the requisite
> >>> offset/etc options.
> >>
> >>
> >> I thought of using uniform buffer data structure with certain flags
> which
> >> differentiate between atomics, uniforms, index. Like a generic buffer.
> >>
> >>>
> >>> I feel like I've mentioned this before when you asked questions, but
> >>> I'd highly recommend taking my work and improving on it (or at least
> >>> understanding it). It's at the point where a driver can implement the
> >>> backend logic, although some of the mesa/st bits are going to be
> >>> subject to discussion (and need fixing, it messes up the DCE tgsi
> >>> pass, so I just disabled it).
> >>>
> >>> On Thu, Nov 13, 2014 at 12:18 AM, adityaatluri <
> adityaavina...@gmail.com>
> >>> wrote:
> >>> > ---
> >>> > src/gallium/include/pipe/p_context.h | 5 +
> >>> > src/gallium/include/pipe/p_defines.h | 7 ++-
> >>> > src/gallium/include/pipe/p_state.h | 10 ++
> >>> > 3 files changed, 21 insertions(+), 1 deletion(-)
> >>> >
> >>> > diff --git a/src/gallium/include/pipe/p_context.h
> >>> > b/src/gallium/include/pipe/p_context.h
> >>> > index af5674f..bf3be31 100644
> >>> > --- a/src/gallium/include/pipe/p_context.h
> >>> > +++ b/src/gallium/include/pipe/p_context.h
> >>> > @@ -44,6 +44,7 @@ struct pipe_blit_info;
> >>> > struct pipe_box;
> >>> > struct pipe_clip_state;
> >>> > struct pipe_constant_buffer;
> >>> > +struct pipe_counter_buffer;
> >>> > struct pipe_depth_stencil_alpha_state;
> >>> > struct pipe_draw_info;
> >>> > struct pipe_fence_handle;
> >>> > @@ -201,6 +202,10 @@ struct pipe_context {
> >>> > uint shader, uint inde
Re: [Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Hi,
I am having difficulty in understanding why you implemented pipe_surface in
st_atom_atomicbuf.c.
On Mon, Nov 17, 2014 at 2:24 AM, Aditya Avinash
wrote:
> Hi,
>
> On Sunday, November 16, 2014, Ilia Mirkin wrote:
>
>> The direction I went in was by adapting the shader resources interface
>> for this. I believe it will be possible to use for
>> shader_image_load_store as well.
>>
>
> I asked some questions on mailing list about the implementation. I took
> the same path as uniform buffers. But, I realized that it's not efficient
> to do that.
>
>
>> See https://github.com/imirkin/mesa/commits/atomic
>>
>>
> The commits are similar to my previous patch. I was doing atomics similar
> to uniform buffers, Now I was changing cso_context.
>
>
>> I believe that makes a lot more sense than creating a special counter
>> buffer type only to be used for this. pipe_surface has the requisite
>> offset/etc options.
>
>
> I thought of using uniform buffer data structure with certain flags which
> differentiate between atomics, uniforms, index. Like a generic buffer.
>
>
>> I feel like I've mentioned this before when you asked questions, but
>> I'd highly recommend taking my work and improving on it (or at least
>> understanding it). It's at the point where a driver can implement the
>> backend logic, although some of the mesa/st bits are going to be
>> subject to discussion (and need fixing, it messes up the DCE tgsi
>> pass, so I just disabled it).
>>
>> On Thu, Nov 13, 2014 at 12:18 AM, adityaatluri
>> wrote:
>> > ---
>> > src/gallium/include/pipe/p_context.h | 5 +
>> > src/gallium/include/pipe/p_defines.h | 7 ++-
>> > src/gallium/include/pipe/p_state.h | 10 ++
>> > 3 files changed, 21 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> > index af5674f..bf3be31 100644
>> > --- a/src/gallium/include/pipe/p_context.h
>> > +++ b/src/gallium/include/pipe/p_context.h
>> > @@ -44,6 +44,7 @@ struct pipe_blit_info;
>> > struct pipe_box;
>> > struct pipe_clip_state;
>> > struct pipe_constant_buffer;
>> > +struct pipe_counter_buffer;
>> > struct pipe_depth_stencil_alpha_state;
>> > struct pipe_draw_info;
>> > struct pipe_fence_handle;
>> > @@ -201,6 +202,10 @@ struct pipe_context {
>> > uint shader, uint index,
>> > struct pipe_constant_buffer *buf );
>> >
>> > + void (*set_counter_buffer)( struct pipe_context *,
>> > + uint shader, uint index,
>> > + struct pipe_counter_buffer *buf );
>> > +
>> > void (*set_framebuffer_state)( struct pipe_context *,
>> >const struct pipe_framebuffer_state
>> * );
>> >
>> > diff --git a/src/gallium/include/pipe/p_defines.h
>> b/src/gallium/include/pipe/p_defines.h
>> > index 8c4e415..717ab6a 100644
>> > --- a/src/gallium/include/pipe/p_defines.h
>> > +++ b/src/gallium/include/pipe/p_defines.h
>> > @@ -341,6 +341,7 @@ enum pipe_flush_flags {
>> > #define PIPE_BIND_VERTEX_BUFFER(1 << 4) /* set_vertex_buffers
>> */
>> > #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */
>> > #define PIPE_BIND_CONSTANT_BUFFER (1 << 6) /* set_constant_buffer
>> */
>> > +#define PIPE_BIND_COUNTER_BUFFER (1 << 7) /* set_counter_buffer
>> */
>> > #define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer
>> */
>> > #define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* transfer_map */
>> > #define PIPE_BIND_TRANSFER_READ(1 << 10) /* transfer_map */
>> > @@ -572,6 +573,8 @@ enum pipe_cap {
>> > PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109,
>> > PIPE_CAP_SAMPLER_VIEW_TARGET = 110,
>> > PIPE_CAP_CLIP_HALFZ = 111,
>> > + PIPE_CAP_USER_COUNTER_BUFFERS = 112,
>> > + PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113,
>> > };
>> >
>> > #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
>> > @@ -631,7 +634,9 @@ enum pipe_shader_cap
>> > PIPE_SHADER_CAP_PREFERRED_IR,
>> > PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED,
>> > PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS,
>> > - PIPE_SHADER_CAP_DOUBLES
>>
Re: [Mesa-dev] [PATCH] gallium/include/pipe: Added interface for atomic counter buffers in pipe
Hi,
On Sunday, November 16, 2014, Ilia Mirkin wrote:
> The direction I went in was by adapting the shader resources interface
> for this. I believe it will be possible to use for
> shader_image_load_store as well.
>
I asked some questions on mailing list about the implementation. I took the
same path as uniform buffers. But, I realized that it's not efficient to do
that.
> See https://github.com/imirkin/mesa/commits/atomic
>
>
The commits are similar to my previous patch. I was doing atomics similar
to uniform buffers, Now I was changing cso_context.
> I believe that makes a lot more sense than creating a special counter
> buffer type only to be used for this. pipe_surface has the requisite
> offset/etc options.
I thought of using uniform buffer data structure with certain flags which
differentiate between atomics, uniforms, index. Like a generic buffer.
> I feel like I've mentioned this before when you asked questions, but
> I'd highly recommend taking my work and improving on it (or at least
> understanding it). It's at the point where a driver can implement the
> backend logic, although some of the mesa/st bits are going to be
> subject to discussion (and need fixing, it messes up the DCE tgsi
> pass, so I just disabled it).
>
> On Thu, Nov 13, 2014 at 12:18 AM, adityaatluri > wrote:
> > ---
> > src/gallium/include/pipe/p_context.h | 5 +
> > src/gallium/include/pipe/p_defines.h | 7 ++-
> > src/gallium/include/pipe/p_state.h | 10 ++
> > 3 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> > index af5674f..bf3be31 100644
> > --- a/src/gallium/include/pipe/p_context.h
> > +++ b/src/gallium/include/pipe/p_context.h
> > @@ -44,6 +44,7 @@ struct pipe_blit_info;
> > struct pipe_box;
> > struct pipe_clip_state;
> > struct pipe_constant_buffer;
> > +struct pipe_counter_buffer;
> > struct pipe_depth_stencil_alpha_state;
> > struct pipe_draw_info;
> > struct pipe_fence_handle;
> > @@ -201,6 +202,10 @@ struct pipe_context {
> > uint shader, uint index,
> > struct pipe_constant_buffer *buf );
> >
> > + void (*set_counter_buffer)( struct pipe_context *,
> > + uint shader, uint index,
> > + struct pipe_counter_buffer *buf );
> > +
> > void (*set_framebuffer_state)( struct pipe_context *,
> >const struct pipe_framebuffer_state *
> );
> >
> > diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> > index 8c4e415..717ab6a 100644
> > --- a/src/gallium/include/pipe/p_defines.h
> > +++ b/src/gallium/include/pipe/p_defines.h
> > @@ -341,6 +341,7 @@ enum pipe_flush_flags {
> > #define PIPE_BIND_VERTEX_BUFFER(1 << 4) /* set_vertex_buffers */
> > #define PIPE_BIND_INDEX_BUFFER (1 << 5) /* draw_elements */
> > #define PIPE_BIND_CONSTANT_BUFFER (1 << 6) /* set_constant_buffer
> */
> > +#define PIPE_BIND_COUNTER_BUFFER (1 << 7) /* set_counter_buffer */
> > #define PIPE_BIND_DISPLAY_TARGET (1 << 8) /* flush_front_buffer */
> > #define PIPE_BIND_TRANSFER_WRITE (1 << 9) /* transfer_map */
> > #define PIPE_BIND_TRANSFER_READ(1 << 10) /* transfer_map */
> > @@ -572,6 +573,8 @@ enum pipe_cap {
> > PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE = 109,
> > PIPE_CAP_SAMPLER_VIEW_TARGET = 110,
> > PIPE_CAP_CLIP_HALFZ = 111,
> > + PIPE_CAP_USER_COUNTER_BUFFERS = 112,
> > + PIPE_CAP_COUNTER_BUFFER_OFFSET_ALIGNMENT = 113,
> > };
> >
> > #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
> > @@ -631,7 +634,9 @@ enum pipe_shader_cap
> > PIPE_SHADER_CAP_PREFERRED_IR,
> > PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED,
> > PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS,
> > - PIPE_SHADER_CAP_DOUBLES
> > + PIPE_SHADER_CAP_DOUBLES,
> > + PIPE_SHADER_CAP_MAX_COUNTER_BUFFER_SIZE,
> > + PIPE_SHADER_CAP_MAX_COUNTER_BUFFERS
> > };
> >
> > /**
> > diff --git a/src/gallium/include/pipe/p_state.h
> b/src/gallium/include/pipe/p_state.h
> > index 43bc48b..49fae5d 100644
> > --- a/src/gallium/include/pipe/p_state.h
> > +++ b/src/gallium/include/pipe/p_state.h
> > @@ -57,6 +57,7 @@ extern "C" {
> > #define PIPE_MAX_CLIP_PLANES 8
> > #define PIPE_MAX_COLOR_BUFS8
> > #define PIPE_MAX_CONSTANT_BUFFERS 32
> > +#define PIPE_MAX_COUNTER_BUFFERS 32
> > #define PIPE_MAX_SAMPLERS 16
> > #define PIPE_MAX_SHADER_INPUTS32
> > #define PIPE_MAX_SHADER_OUTPUTS 48 /* 32 GENERICs + POS, PSIZE, FOG,
> etc. */
> > @@ -462,6 +463,15 @@ struct pipe_constant_buffer {
> > const void *user_buffer; /**< pointer to a user buffer if buffer ==
> NULL */
> > };
> >
> > +/**
> > + * A Counter buffer. A new buffer is set everytime a variable with
> > + * atomic_uint is defined.
> > + */
> > +struct pipe_counter_buffer{
> > + struct pipe_resourc
[Mesa-dev] Request for more info in implementing atomic counters in mesa state tracker
Hi, I am currently working on implementing the extension *GL_ARB_shader_atomic_counters*. I have a few questions. 1. What does CSO and cso_context for? Why do we have to bind with it? 2. There is a file called st_atom_constbuf.c/.h in mesa/state_tracker. As counter buffers are different from constant buffers, is it ok to create a new file say, st_atom_countbuf.c/.h? 3. Counter buffers dont do "upload_data". But, they take offsets. Do I have to create a new cso api say cso_set_counter_buffer(**) to upload the data or can use the cso_st_constant_buffer interface with some of the variables set to NULL? 4. The st_context has struct state.constants this data type takes void pointer and size which are specific to constant buffers. Do we have to create something similar to that or can we ignore it (no pointer and size are needed for counters)? -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main/mesa: missing atomic buffer bindings to mesa are added in this patch
Hi,
Do you want me to resend it?
On Thursday, July 24, 2014, Matt Turner wrote:
> The commit message should be something like
>
> "mesa: Add missing atomic buffer bindings and unbindings."
>
> On Thu, Jul 24, 2014 at 12:18 PM, Aditya Atluri
> > wrote:
> > ---
> > src/mesa/main/bufferobj.c | 31 +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> > index 7b1bba0..1dfcda3 100644
> > --- a/src/mesa/main/bufferobj.c
> > +++ b/src/mesa/main/bufferobj.c
> > @@ -832,6 +832,9 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
> > _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer,
> > ctx->Shared->NullBufferObj);
> >
> > + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer,
> > +ctx->Shared->NullBufferObj);
> > +
> > _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer,
> > ctx->Shared->NullBufferObj);
> >
> > @@ -842,6 +845,14 @@ _mesa_init_buffer_objects( struct gl_context *ctx )
> >ctx->UniformBufferBindings[i].Offset = -1;
> >ctx->UniformBufferBindings[i].Size = -1;
> > }
> > +
> > + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> > + _mesa_reference_buffer_object(ctx,
> > +
> &ctx->AtomicBufferBindings[i].BufferObject,
> > + ctx->Shared->NullBufferObj);
> > + ctx->AtomicBufferBindings[i].Offset = -1;
> > + ctx->AtomicBufferBindings[i].Size = -1;
> > + }
> > }
> >
> >
> > @@ -857,6 +868,8 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
> >
> > _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);
> >
> > + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer, NULL);
> > +
> > _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer, NULL);
> >
> > for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
> > @@ -864,6 +877,13 @@ _mesa_free_buffer_objects( struct gl_context *ctx )
> >
> &ctx->UniformBufferBindings[i].BufferObject,
> > NULL);
> > }
> > +
> > + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> > + _mesa_reference_buffer_object(ctx,
> > +
> &ctx->AtomicBufferBindings[i].BufferObject,
> > + NULL);
> > + }
> > +
> > }
> >
> > bool
> > @@ -1200,6 +1220,17 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint *ids)
> > _mesa_BindBuffer( GL_UNIFORM_BUFFER, 0 );
> > }
> >
> > + /* unbind Atomci Buffer binding points */
>
> Atomic
>
--
Regards,
*Aditya Atluri,*
*USA.*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] added functions for binding atomic buffers to extension GL_ARB_shader_atomic_counters for radeonsi and r600 backend
Hi,
I am sorry. This is my first patch. I'll correct it for the next time. Do
you want me to resend it?
On Wednesday, July 23, 2014, Ian Romanick wrote:
> On 07/23/2014 12:39 PM, Marek Olšák wrote:
> > I thought so too, but these bits are really missing there, e.g.
> > glDeleteBuffers doesn't unbind atomic buffers, etc.
>
> D'oh. It sounds like we need some piglit tests and probably some spec
> quotations. :(
>
> > Marek
> >
> > On Wed, Jul 23, 2014 at 9:25 PM, Ilia Mirkin > wrote:
> >> On Wed, Jul 23, 2014 at 3:22 PM, Marek Olšák > wrote:
> >>> Please see:
> >>>
> >>> http://lists.freedesktop.org/archives/mesa-dev/2014-July/062818.html
> >>> http://lists.freedesktop.org/archives/mesa-dev/2014-July/063798.html
> >>>
> >>> Also, your git username and address are wrong. You can set them with
> git config.
> >>
> >> In addition to these more basic issues... is this patch needed at all?
> >> I thought the core code was all done and it was just the mesa/st +
> >> gallium interfaces that needed to be fixed up.
> >>
> >>>
> >>> Marek
> >>>
> >>> On Wed, Jul 23, 2014 at 8:27 PM, Aditya Atluri <
> adityaavina...@gmail.com > wrote:
> From: Frost
>
> ---
> src/mesa/main/bufferobj.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index 7b1bba0..00f2604 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -832,6 +832,9 @@ _mesa_init_buffer_objects( struct gl_context *ctx
> )
> _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer,
> ctx->Shared->NullBufferObj);
>
> + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer,
> + ctx->Shared->NullBufferObj);
> +
> _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer,
> ctx->Shared->NullBufferObj);
>
> @@ -842,6 +845,14 @@ _mesa_init_buffer_objects( struct gl_context
> *ctx )
> ctx->UniformBufferBindings[i].Offset = -1;
> ctx->UniformBufferBindings[i].Size = -1;
> }
> +
> + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> + _mesa_reference_buffer_object(ctx,
> +
> &ctx->AtomicBufferBindings[i].BufferObject,
> +ctx->Shared->NullBufferObj);
> + ctx->AtomicBufferBindings[i].Offset = -1;
> + ctx->AtomicBufferBindings[i].Size = -1;
> + }
> }
>
>
> @@ -857,6 +868,8 @@ _mesa_free_buffer_objects( struct gl_context *ctx
> )
>
> _mesa_reference_buffer_object(ctx, &ctx->UniformBuffer, NULL);
>
> + _mesa_reference_buffer_object(ctx, &ctx->AtomicBuffer, NULL);
> +
> _mesa_reference_buffer_object(ctx, &ctx->DrawIndirectBuffer,
> NULL);
>
> for (i = 0; i < MAX_COMBINED_UNIFORM_BUFFERS; i++) {
> @@ -864,6 +877,12 @@ _mesa_free_buffer_objects( struct gl_context
> *ctx )
>
> &ctx->UniformBufferBindings[i].BufferObject,
> NULL);
> }
> +
> + for (i = 0; i < MAX_COMBINED_ATOMIC_BUFFERS; i++) {
> + _mesa_reference_buffer_object(ctx,
> +
> &ctx->AtomicBufferBindings[i].BufferObject,
> +NULL);
> + }
> }
>
> bool
> @@ -1200,6 +1219,17 @@ _mesa_DeleteBuffers(GLsizei n, const GLuint
> *ids)
> _mesa_BindBuffer( GL_UNIFORM_BUFFER, 0 );
> }
>
> + /* unbind Atomic Buffers binding points */
> + for (j = 0; j < ctx->Const.MaxAtomicBufferBindings; j++) {
> + if (ctx->AtomicBufferBindings[j].BufferObject ==
> bufObj) {
> + _mesa_BindBufferBase( GL_ATOMIC_COUNTER_BUFFER, j,
> 0 );
> + }
> + }
> +
> + if (ctx->AtomicBuffer == bufObj) {
> +_mesa_BindBuffer(GL_ATOMIC_COUNTER_BUFFER, 0);
> + }
> +
> /* unbind any pixel pack/unpack pointers bound to this
> buffer */
> if (ctx->Pack.BufferObj == bufObj) {
> _mesa_BindBuffer( GL_PIXEL_PACK_BUFFER_EXT, 0 );
> --
> 1.7.9.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
> >
>
> ___
> mesa-dev mailing list
>
[Mesa-dev] Mesa-dev Patch: Binding Atomic Buffers to mesa
Hi, In src/mesa/main, the bindings for atomic buffers are made to mesa_init_buffers, mesa_free_buffers, mesa_deletebuffers. Here are the two commits made on Jul 07 2014. https://github.com/adityaatluri/mesa/commits/master -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Request for next steps on GL_shader_atomic_counters
Hi, I have started writing code for GL_shader_atomic_counters[1]. How do I proceed to the next steps? Thank you! [1] https://github.com/adityaatluri/shader_atomic_counters/blob/master/atomic_counters.h -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request for information on Radeon
Hi, Thank you very much. On Tue, Jun 10, 2014 at 5:28 PM, Marek Olšák wrote: > On Tue, Jun 10, 2014 at 10:45 PM, Aditya Avinash > wrote: > > Hi, > > Thank you very much!! > > > > On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák wrote: > >> > >> This is probably one of the most difficult tasks. You'll need to: > >> > >> 1) Add support to Mesa core - new shader stages and the new OpenGL > >> functions and queries (src/mesa/main) > > > > > > Ya. This one is straight forward. The added Tessellation stage should be > > added to the OpenGL pipeline. > > > >> > >> 2) Add support to the GLSL compiler (src/glsl) > > > > > > Ok! > > > >> > >> 3) Add support to the Gallium interface and TGSI > >> (src/gallium/include/pipe) and supporting code (src/gallium/auxiliary) > >> > > > > Can you explain a bit more? > > Gallium is not just a driver interface, it's a full and self-contained > 3D API like OpenGL and Direct3D. It looks a lot like Direct3D 11, so > following its design is usually a good idea, but not required. > > The supporting code is at least: > - TGSI generating and parsing > - u_blitter, which should disable tessellation for all its operations > - some state tracking in cso_context, which you'll need for st/mesa > > Marek > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request for information on Radeon
Hi, On Tue, Jun 10, 2014 at 5:06 PM, Chris Forbes wrote: > For the first two points, a partial implementation is already done here: > > https://github.com/fabe3k/mesa/commits/tessellation > > This predates the addition of ARB_separate_shader_objects, which has > some interactions. There are probably also plenty of rough edges, but > it should give you enough to get started with the gallium/tgsi parts. > Thank you very much! Is there any documentation available or irc logs where I can get more information? As, the code is less commented. Thank you! > On Wed, Jun 11, 2014 at 8:45 AM, Aditya Avinash > wrote: > > Hi, > > Thank you very much!! > > > > On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák wrote: > >> > >> This is probably one of the most difficult tasks. You'll need to: > >> > >> 1) Add support to Mesa core - new shader stages and the new OpenGL > >> functions and queries (src/mesa/main) > > > > > > Ya. This one is straight forward. The added Tessellation stage should be > > added to the OpenGL pipeline. > > > >> > >> 2) Add support to the GLSL compiler (src/glsl) > > > > > > Ok! > > > >> > >> 3) Add support to the Gallium interface and TGSI > >> (src/gallium/include/pipe) and supporting code (src/gallium/auxiliary) > >> > > > > Can you explain a bit more? > > > >> > >> 4) Add support to the Mesa state tracker (src/mesa/state_tracker), > >> which translates everything from Mesa core and GLSL IR to Gallium and > >> TGSI, respectively. > > > > > > Ok! > > > >> > >> 5) Add support to either r600g or radeonsi. For radeonsi, implement > >> the Gallium interface and program all the hardware registers > >> correctly. On the shader side, add support to the TGSI->LLVM IR > >> converter. (src/gallium/drivers/radeonsi) You might also need some > >> small changes in the LLVM shader backend, not sure about that. > >> > > > > Ok! > > > >> > >> 6) Add a lot of of piglit tests. > >> > > Ya! > >> > >> Marek > >> > >> > >> On Sun, Jun 8, 2014 at 2:05 PM, Aditya Avinash < > adityaavina...@gmail.com> > >> wrote: > >> > Hi, > >> > I was looking at RadeonFeature. It shows that Tessellation stage is > >> > "TODO". > >> > What should I do to pick it? I am new to Mesa. Can you help me with > some > >> > documentation which is useful for me to accomplish the task? > >> > Thank you! > >> > > >> > -- > >> > Regards, > >> > Aditya Atluri. > >> > > >> > ___ > >> > mesa-dev mailing list > >> > mesa-dev@lists.freedesktop.org > >> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> > > > > > > > I have been reading about the Tessellation shader and proprietary OpenGL > API > > present at opengl extensions page. > > Where should I get started? > > Thank you very much. > > > > -- > > Regards, > > Aditya Atluri, > > USA. > > > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request for information on Radeon
Hi, Thank you very much!! On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák wrote: > This is probably one of the most difficult tasks. You'll need to: > > 1) Add support to Mesa core - new shader stages and the new OpenGL > functions and queries (src/mesa/main) > Ya. This one is straight forward. The added Tessellation stage should be added to the OpenGL pipeline. > 2) Add support to the GLSL compiler (src/glsl) > Ok! > 3) Add support to the Gallium interface and TGSI > (src/gallium/include/pipe) and supporting code (src/gallium/auxiliary) > > Can you explain a bit more? > 4) Add support to the Mesa state tracker (src/mesa/state_tracker), > which translates everything from Mesa core and GLSL IR to Gallium and > TGSI, respectively. > Ok! > 5) Add support to either r600g or radeonsi. For radeonsi, implement > the Gallium interface and program all the hardware registers > correctly. On the shader side, add support to the TGSI->LLVM IR > converter. (src/gallium/drivers/radeonsi) You might also need some > small changes in the LLVM shader backend, not sure about that. > > Ok! > 6) Add a lot of of piglit tests. > > Ya! > Marek > > > On Sun, Jun 8, 2014 at 2:05 PM, Aditya Avinash > wrote: > > Hi, > > I was looking at RadeonFeature. It shows that Tessellation stage is > "TODO". > > What should I do to pick it? I am new to Mesa. Can you help me with some > > documentation which is useful for me to accomplish the task? > > Thank you! > > > > -- > > Regards, > > Aditya Atluri. > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > I have been reading about the Tessellation shader and proprietary OpenGL API present at opengl extensions page. Where should I get started? Thank you very much. -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Request for information on Radeon
Hi, Thank you!! Can I join them? I have good knowledge on Tessellation using proprietary drivers. I don't know where to start. Can you provide me some documentation on it? Thank you! On Sun, Jun 8, 2014 at 1:00 PM, Matt Turner wrote: > On Sun, Jun 8, 2014 at 5:05 AM, Aditya Avinash > wrote: > > Hi, > > I was looking at RadeonFeature. It shows that Tessellation stage is > "TODO". > > What should I do to pick it? I am new to Mesa. Can you help me with some > > documentation which is useful for me to accomplish the task? > > Thank you! > > There's a Google Summer of Code project that hopes to do a large > portion of Tessellation shaders this summer. > > For a first project, you probably want to attempt something a bit smaller. > -- Regards, *Aditya Atluri,* *USA.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Request for information on Radeon
Hi, I was looking at RadeonFeature. It shows that Tessellation stage is "TODO". What should I do to pick it? I am new to Mesa. Can you help me with some documentation which is useful for me to accomplish the task? Thank you! -- Regards, *Aditya Atluri.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Request for review of GSOC proposal
Hi, Please provide me with the feedback of my GSOC proposal. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/aatluri/5707702298738688 Thank you. -- Regards, *Atluri Aditya Avinash*, India. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL Image Support
Hi Tom, Do I need to have an AMD GPU for compute images to R600? Thank you! On Tue, Mar 18, 2014 at 9:14 PM, Tom Stellard wrote: > On Mon, Mar 17, 2014 at 10:50:18PM -0400, Aditya Avinash wrote: > > Hi, > > I am a student. I have experience in OpenCL for 3 years. I would like to > > know what need to be done exactly. > > > > Hi, > > The first thing you need to do is write a proposal. I would recommend > writing a rough draft, uploading it to the Google Summer Code site and > then mailing a copy to the list for review. You can edit your proposal > on the Google Summer of Code site right up until the deadline, so you > don't need to wait until you have a final draft to upload it. > > The more feedback you can get on your proposal before the deadline > (which is in about two days) the better your proposal will be. > > If you have any specific questions about this project or need help > getting started, don't be afraid to ask. At a high level, this project > can be broken down like this: > > 1. Find and/or write simple OpenCL programs (preferably piglit[1] tests) > that use images. > > 2. Add image builtins to libclc[2] > > 3. Implement the gallium callbacks used by clover[3] for images. > > 4. Add support for compute images to the R600 LLVM[4] backend. > > > -Tom > > [1] http://cgit.freedesktop.org/piglit > [2] http://libclc.llvm.org/ > [3] > http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clover > [4] https://github.com/llvm-mirror/llvm/tree/master/lib/Target/R600 > > -- Regards, *Atluri Aditya Avinash*, India. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OpenCL Image Support
Hi, I am a student. I have experience in OpenCL for 3 years. I would like to know what need to be done exactly. Thank you -- Regards, *Atluri Aditya Avinash.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
