Re: [Mesa-dev] [RFC 1/3] tgsi: Add WORK_DIM System Value
On 05:43 PM - Apr 27 2016, Samuel Pitoiset wrote: > > > On 04/27/2016 05:24 PM, Ilia Mirkin wrote: > >On Wed, Apr 27, 2016 at 11:19 AM, Hans de Goede wrote: > >>Hi, > >> > >>On 27-04-16 16:49, Ilia Mirkin wrote: > >>> > >>>Please add this semantic to src/gallium/docs and explain what it > >>>means. > >> > >> > >>Ah, I was under the impression these were not documented, but I > >>now see they are, will fix. > >> > >>>(I'm not even sure what this is, and the easily-found opencl > >>> > >>>docs helpfully indicate that get_work_dim returns the work_dim...) > >>>This wasn't done for some of the other compute-specific semantics. > >> > >> > >>When launching a grid through clEnqueueNDRangeKernel the user > >>can tell how many dimensions of the pipe_grid_info->grid / > >>pipe_grid_info->block equivalent the user is actually passing in > >>this is done through a parameter to that function called work_dim: > >> > >>https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clEnqueueNDRangeKernel.html > >> > >>Clover pads the y and z values (if unused) to 1, so it always > >>ends up giving a 3 dimensional grid and block sizes to the driver. > >> > >>But an opencl kernel can use the opencl builtin get_work_dim > >>function, which returns how much dimensions where actually > >>passed into clEnqueueNDRangeKernel. > >> > >>Note that passing in e.g. work_dim = 3 with a grid size of { 4, 1, 1 } > >>is perfectly legal and then get_work_dim should actually return 3. > >> > >>So we need to store the clEnqueueNDRangeKernel workdim parameter > >>somewhere, and allow getting it from a kernel. Using a system-value > >>seems the best solution for this to me. > >> > >>I hope this helps to explain things, if not keep asking :) > >> > >>Also if you've a better solution, I'm all ears. > > > >Sounds like there's no real way to distinguish it from the kernel, the > >parameters given to the hw are all the same, so it's just a thing that > >needs to be passed along. I think that what you have is a fine > >solution, although I question the usefulness of this being an OpenCL > >builtin. But we're not about to change that now. > > > >An alternative would be for clover to stick it into a uniform and have > >the kernel read it out from there. If there are going to be a ton of > >these, that might be preferable. If it's just the one (or maybe two), > >not worth it. > > I think your solution is fine too. Storing the number of dimensions passed > to clEnqueueNDRangeKernel() as well as the local/global sizes makes sense. Later versions of OpenCL are adding a few more of those (see [OpenCL 1.0][1] compared to [OpenCL 2.0][2]). So putting it in a uniform would be better, but we can just switch to a uniform the day we reach OpenCL 2.0. Pierre [1]: https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/workItemFunctions.html [2]: https://www.khronos.org/registry/cl/sdk/2.0/docs/man/xhtml/workItemFunctions.html > > > > > -ilia > > > > -- > -Samuel > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 1/3] tgsi: Add WORK_DIM System Value
Hi, On 28-04-16 10:13, Pierre Moreau wrote: On 05:43 PM - Apr 27 2016, Samuel Pitoiset wrote: On 04/27/2016 05:24 PM, Ilia Mirkin wrote: On Wed, Apr 27, 2016 at 11:19 AM, Hans de Goede wrote: Hi, On 27-04-16 16:49, Ilia Mirkin wrote: Please add this semantic to src/gallium/docs and explain what it means. Ah, I was under the impression these were not documented, but I now see they are, will fix. (I'm not even sure what this is, and the easily-found opencl docs helpfully indicate that get_work_dim returns the work_dim...) This wasn't done for some of the other compute-specific semantics. When launching a grid through clEnqueueNDRangeKernel the user can tell how many dimensions of the pipe_grid_info->grid / pipe_grid_info->block equivalent the user is actually passing in this is done through a parameter to that function called work_dim: https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clEnqueueNDRangeKernel.html Clover pads the y and z values (if unused) to 1, so it always ends up giving a 3 dimensional grid and block sizes to the driver. But an opencl kernel can use the opencl builtin get_work_dim function, which returns how much dimensions where actually passed into clEnqueueNDRangeKernel. Note that passing in e.g. work_dim = 3 with a grid size of { 4, 1, 1 } is perfectly legal and then get_work_dim should actually return 3. So we need to store the clEnqueueNDRangeKernel workdim parameter somewhere, and allow getting it from a kernel. Using a system-value seems the best solution for this to me. I hope this helps to explain things, if not keep asking :) Also if you've a better solution, I'm all ears. Sounds like there's no real way to distinguish it from the kernel, the parameters given to the hw are all the same, so it's just a thing that needs to be passed along. I think that what you have is a fine solution, although I question the usefulness of this being an OpenCL builtin. But we're not about to change that now. An alternative would be for clover to stick it into a uniform and have the kernel read it out from there. If there are going to be a ton of these, that might be preferable. If it's just the one (or maybe two), not worth it. I think your solution is fine too. Storing the number of dimensions passed to clEnqueueNDRangeKernel() as well as the local/global sizes makes sense. Later versions of OpenCL are adding a few more of those (see [OpenCL 1.0][1] compared to [OpenCL 2.0][2]). So putting it in a uniform would be better, but we can just switch to a uniform the day we reach OpenCL 2.0. It looks like most of these can be implemented using libclc wrappers around the existing workitem functions. Regards, Hans ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 1/3] tgsi: Add WORK_DIM System Value
Please add this semantic to src/gallium/docs and explain what it means. (I'm not even sure what this is, and the easily-found opencl docs helpfully indicate that get_work_dim returns the work_dim...) This wasn't done for some of the other compute-specific semantics. Is this the equivalent of gl_LocalGroupSizeARB from GL_ARB_compute_variable_group_size ? [which is basically the same as gl_WorkGroupSize, but allowed to be specified at dispatch time] On Wed, Apr 27, 2016 at 10:43 AM, Hans de Goede wrote: > Add a new WORK_DIM SV type, this is will return the grid dimensions > (1-4) for compute (opencl) kernels. > > This is necessary to implement the opencl get_work_dim() function. > > Signed-off-by: Hans de Goede > --- > src/gallium/auxiliary/tgsi/tgsi_strings.c | 1 + > src/gallium/include/pipe/p_shader_tokens.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c > b/src/gallium/auxiliary/tgsi/tgsi_strings.c > index 894d475..f65d7b4 100644 > --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c > +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c > @@ -100,6 +100,7 @@ const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT] = > "HELPER_INVOCATION", > "BASEINSTANCE", > "DRAWID", > + "WORK_DIM", > }; > > const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] = > diff --git a/src/gallium/include/pipe/p_shader_tokens.h > b/src/gallium/include/pipe/p_shader_tokens.h > index 514b339..d8ded50 100644 > --- a/src/gallium/include/pipe/p_shader_tokens.h > +++ b/src/gallium/include/pipe/p_shader_tokens.h > @@ -200,6 +200,7 @@ enum tgsi_semantic { > TGSI_SEMANTIC_HELPER_INVOCATION, /**< current invocation is helper */ > TGSI_SEMANTIC_BASEINSTANCE, > TGSI_SEMANTIC_DRAWID, > + TGSI_SEMANTIC_WORK_DIM,/**< opencl get_work_dim value */ > TGSI_SEMANTIC_COUNT, /**< number of semantic values */ > }; > > -- > 2.7.4 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 1/3] tgsi: Add WORK_DIM System Value
Hi, On 27-04-16 16:49, Ilia Mirkin wrote: Please add this semantic to src/gallium/docs and explain what it means. Ah, I was under the impression these were not documented, but I now see they are, will fix. > (I'm not even sure what this is, and the easily-found opencl docs helpfully indicate that get_work_dim returns the work_dim...) This wasn't done for some of the other compute-specific semantics. When launching a grid through clEnqueueNDRangeKernel the user can tell how many dimensions of the pipe_grid_info->grid / pipe_grid_info->block equivalent the user is actually passing in this is done through a parameter to that function called work_dim: https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clEnqueueNDRangeKernel.html Clover pads the y and z values (if unused) to 1, so it always ends up giving a 3 dimensional grid and block sizes to the driver. But an opencl kernel can use the opencl builtin get_work_dim function, which returns how much dimensions where actually passed into clEnqueueNDRangeKernel. Note that passing in e.g. work_dim = 3 with a grid size of { 4, 1, 1 } is perfectly legal and then get_work_dim should actually return 3. So we need to store the clEnqueueNDRangeKernel workdim parameter somewhere, and allow getting it from a kernel. Using a system-value seems the best solution for this to me. I hope this helps to explain things, if not keep asking :) Also if you've a better solution, I'm all ears. Regards, Hans Is this the equivalent of gl_LocalGroupSizeARB from GL_ARB_compute_variable_group_size ? [which is basically the same as gl_WorkGroupSize, but allowed to be specified at dispatch time] On Wed, Apr 27, 2016 at 10:43 AM, Hans de Goede wrote: Add a new WORK_DIM SV type, this is will return the grid dimensions (1-4) for compute (opencl) kernels. This is necessary to implement the opencl get_work_dim() function. Signed-off-by: Hans de Goede --- src/gallium/auxiliary/tgsi/tgsi_strings.c | 1 + src/gallium/include/pipe/p_shader_tokens.h | 1 + 2 files changed, 2 insertions(+) diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c b/src/gallium/auxiliary/tgsi/tgsi_strings.c index 894d475..f65d7b4 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c @@ -100,6 +100,7 @@ const char *tgsi_semantic_names[TGSI_SEMANTIC_COUNT] = "HELPER_INVOCATION", "BASEINSTANCE", "DRAWID", + "WORK_DIM", }; const char *tgsi_texture_names[TGSI_TEXTURE_COUNT] = diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h index 514b339..d8ded50 100644 --- a/src/gallium/include/pipe/p_shader_tokens.h +++ b/src/gallium/include/pipe/p_shader_tokens.h @@ -200,6 +200,7 @@ enum tgsi_semantic { TGSI_SEMANTIC_HELPER_INVOCATION, /**< current invocation is helper */ TGSI_SEMANTIC_BASEINSTANCE, TGSI_SEMANTIC_DRAWID, + TGSI_SEMANTIC_WORK_DIM,/**< opencl get_work_dim value */ TGSI_SEMANTIC_COUNT, /**< number of semantic values */ }; -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 1/3] tgsi: Add WORK_DIM System Value
On Wed, Apr 27, 2016 at 11:19 AM, Hans de Goede wrote: > Hi, > > On 27-04-16 16:49, Ilia Mirkin wrote: >> >> Please add this semantic to src/gallium/docs and explain what it >> means. > > > Ah, I was under the impression these were not documented, but I > now see they are, will fix. > >> (I'm not even sure what this is, and the easily-found opencl >> >> docs helpfully indicate that get_work_dim returns the work_dim...) >> This wasn't done for some of the other compute-specific semantics. > > > When launching a grid through clEnqueueNDRangeKernel the user > can tell how many dimensions of the pipe_grid_info->grid / > pipe_grid_info->block equivalent the user is actually passing in > this is done through a parameter to that function called work_dim: > > https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clEnqueueNDRangeKernel.html > > Clover pads the y and z values (if unused) to 1, so it always > ends up giving a 3 dimensional grid and block sizes to the driver. > > But an opencl kernel can use the opencl builtin get_work_dim > function, which returns how much dimensions where actually > passed into clEnqueueNDRangeKernel. > > Note that passing in e.g. work_dim = 3 with a grid size of { 4, 1, 1 } > is perfectly legal and then get_work_dim should actually return 3. > > So we need to store the clEnqueueNDRangeKernel workdim parameter > somewhere, and allow getting it from a kernel. Using a system-value > seems the best solution for this to me. > > I hope this helps to explain things, if not keep asking :) > > Also if you've a better solution, I'm all ears. Sounds like there's no real way to distinguish it from the kernel, the parameters given to the hw are all the same, so it's just a thing that needs to be passed along. I think that what you have is a fine solution, although I question the usefulness of this being an OpenCL builtin. But we're not about to change that now. An alternative would be for clover to stick it into a uniform and have the kernel read it out from there. If there are going to be a ton of these, that might be preferable. If it's just the one (or maybe two), not worth it. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 1/3] tgsi: Add WORK_DIM System Value
On 04/27/2016 05:24 PM, Ilia Mirkin wrote: On Wed, Apr 27, 2016 at 11:19 AM, Hans de Goede wrote: Hi, On 27-04-16 16:49, Ilia Mirkin wrote: Please add this semantic to src/gallium/docs and explain what it means. Ah, I was under the impression these were not documented, but I now see they are, will fix. (I'm not even sure what this is, and the easily-found opencl docs helpfully indicate that get_work_dim returns the work_dim...) This wasn't done for some of the other compute-specific semantics. When launching a grid through clEnqueueNDRangeKernel the user can tell how many dimensions of the pipe_grid_info->grid / pipe_grid_info->block equivalent the user is actually passing in this is done through a parameter to that function called work_dim: https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clEnqueueNDRangeKernel.html Clover pads the y and z values (if unused) to 1, so it always ends up giving a 3 dimensional grid and block sizes to the driver. But an opencl kernel can use the opencl builtin get_work_dim function, which returns how much dimensions where actually passed into clEnqueueNDRangeKernel. Note that passing in e.g. work_dim = 3 with a grid size of { 4, 1, 1 } is perfectly legal and then get_work_dim should actually return 3. So we need to store the clEnqueueNDRangeKernel workdim parameter somewhere, and allow getting it from a kernel. Using a system-value seems the best solution for this to me. I hope this helps to explain things, if not keep asking :) Also if you've a better solution, I'm all ears. Sounds like there's no real way to distinguish it from the kernel, the parameters given to the hw are all the same, so it's just a thing that needs to be passed along. I think that what you have is a fine solution, although I question the usefulness of this being an OpenCL builtin. But we're not about to change that now. An alternative would be for clover to stick it into a uniform and have the kernel read it out from there. If there are going to be a ton of these, that might be preferable. If it's just the one (or maybe two), not worth it. I think your solution is fine too. Storing the number of dimensions passed to clEnqueueNDRangeKernel() as well as the local/global sizes makes sense. -ilia -- -Samuel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev