search for: launch_grid

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/state_trackers/clover/core/kernel.cpp | 2 +- 1 file changed, 1 insertion(+), 1...

...not something workable in the long run, I've tried to rewrite the test to use a global buffer (not sure this is the best approach other ideas are welcome), leading to this diff: --- a/src/gallium/tests/trivial/compute.c +++ b/src/gallium/tests/trivial/compute.c @@ -431,7 +431,6 @@ static void launch_grid(struct context *ctx, const uint *block_layout, static void test_system_values(struct context *ctx) { const char *src = "COMP\n" - "DCL RES[0], BUFFER, RAW, WR\n" "DCL SV[0], BLOCK_ID[0]\n" "DCL SV[1]...

Hi, On 14-03-16 14:01, Samuel Pitoiset wrote: > > > On 03/14/2016 01:50 PM, Hans de Goede wrote: >> After pipe_grid_info.indirect was introduced, clover was not modified >> to set it causing it to pass uninitialized memory for it to launch_grid. >> >> This commit fixes this by zero-ing the entire pipe_grid_info struct when >> declaring it, to avoid similar problems popping-up in the future. >> >> Signed-off-by: Hans de Goede <hdegoede at redhat.com> >> --- >> src/gallium/state_trackers/clo...

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Cc: "11.2" <mesa-stable at lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Drop traili...

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Cc: "11.2" <mesa-stable at lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Drop traili...

...3-16 14:01, Samuel Pitoiset wrote: >>> >>> >>> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>>> After pipe_grid_info.indirect was introduced, clover was not modified >>>> to set it causing it to pass uninitialized memory for it to >>>> launch_grid. >>>> >>>> This commit fixes this by zero-ing the entire pipe_grid_info struct >>>> when >>>> declaring it, to avoid similar problems popping-up in the future. >>>> >>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com&g...

On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > On 22-02-16 14:47, Ilia Mirkin wrote: >> >> On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>> >>> INPUT is for shader inputs which come from fixed function loaders. >>> This is not what you want. You want CONST. Stick

...nnot work with your suggestion, > but it is something to keep in mind. > > I've not yet looked closely at const bufs, I've only been working with > global buffers so far, here is how I understand those to work: > > -clover calls pipe->set_global_binding() before calling launch_grid() > -clover has set up the uint32_t **handles pointer array to point to > one uint32_t in the buffer which it is going to pass as "input" to > launch_grid for each global buffer > -In the tgsi code for the kernel I can get to the global buffer pointed > to by the first u...

...39;m not saying that this cannot work with your suggestion, but it is something to keep in mind. I've not yet looked closely at const bufs, I've only been working with global buffers so far, here is how I understand those to work: -clover calls pipe->set_global_binding() before calling launch_grid() -clover has set up the uint32_t **handles pointer array to point to one uint32_t in the buffer which it is going to pass as "input" to launch_grid for each global buffer -In the tgsi code for the kernel I can get to the global buffer pointed to by the first uint32_t in the input d...

...ended >> to you? >> >> 2) This only solves the accessing of the global memory, it does not solve >> getting to the kernel input kernel parameters, how would I deal with >> those ? > > The input kernel parameters are directly passed through a call to pipe_context::launch_grid. You just have to fill the pipe_grid_info::input array with your parameters and they will be uploaded by nvXX_compute_upload_input(). Right, the uploading side I understand, the question is how to get to them from the compute kernel's tgsi code ? If I understand you correctly you are suggesti...

...he accessing of the global memory, it does not >>>> solve >>>> getting to the kernel input kernel parameters, how would I deal with >>>> those ? >>> >>> The input kernel parameters are directly passed through a call to >>> pipe_context::launch_grid. You just have to fill the >>> pipe_grid_info::input array with your parameters and they will be >>> uploaded by nvXX_compute_upload_input(). >> >> Right, the uploading side I understand, the question is how to get to >> them from >> the compute kernel'...

...estion, >> but it is something to keep in mind. >> >> I've not yet looked closely at const bufs, I've only been working with >> global buffers so far, here is how I understand those to work: >> >> -clover calls pipe->set_global_binding() before calling launch_grid() >> -clover has set up the uint32_t **handles pointer array to point to >> one uint32_t in the buffer which it is going to pass as "input" to >> launch_grid for each global buffer >> -In the tgsi code for the kernel I can get to the global buffer pointed >&...

On 03/14/2016 01:50 PM, Hans de Goede wrote: > After pipe_grid_info.indirect was introduced, clover was not modified > to set it causing it to pass uninitialized memory for it to launch_grid. > > This commit fixes this by zero-ing the entire pipe_grid_info struct when > declaring it, to avoid similar problems popping-up in the future. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > src/gallium/state_trackers/clover/core/kernel.cpp | 2 +- &...

...ede wrote: > Hi, > > On 14-03-16 14:01, Samuel Pitoiset wrote: >> >> >> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>> After pipe_grid_info.indirect was introduced, clover was not modified >>> to set it causing it to pass uninitialized memory for it to launch_grid. >>> >>> This commit fixes this by zero-ing the entire pipe_grid_info struct when >>> declaring it, to avoid similar problems popping-up in the future. >>> >>> Signed-off-by: Hans de Goede <hdegoede at redhat.com> >>> --- >>> sr...

...set wrote: >>>> >>>> >>>> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>>>> After pipe_grid_info.indirect was introduced, clover was not modified >>>>> to set it causing it to pass uninitialized memory for it to >>>>> launch_grid. >>>>> >>>>> This commit fixes this by zero-ing the entire pipe_grid_info struct >>>>> when >>>>> declaring it, to avoid similar problems popping-up in the future. >>>>> >>>>> Signed-off-by: Hans de Goede <...

...al memory, it does not >>>>> solve >>>>> getting to the kernel input kernel parameters, how would I deal with >>>>> those ? >>>> >>>> The input kernel parameters are directly passed through a call to >>>> pipe_context::launch_grid. You just have to fill the >>>> pipe_grid_info::input array with your parameters and they will be >>>> uploaded by nvXX_compute_upload_input(). >>> >>> Right, the uploading side I understand, the question is how to get to >>> them from >>>...

...s not >>>>> solve >>>>> getting to the kernel input kernel parameters, how would I deal with >>>>> those ? >>>> >>>> >>>> The input kernel parameters are directly passed through a call to >>>> pipe_context::launch_grid. You just have to fill the >>>> pipe_grid_info::input array with your parameters and they will be >>>> uploaded by nvXX_compute_upload_input(). >>> >>> >>> Right, the uploading side I understand, the question is how to get to >>> them from...

...t; 2) This only solves the accessing of the global memory, it does not >>> solve >>> getting to the kernel input kernel parameters, how would I deal with >>> those ? >> >> The input kernel parameters are directly passed through a call to >> pipe_context::launch_grid. You just have to fill the >> pipe_grid_info::input array with your parameters and they will be >> uploaded by nvXX_compute_upload_input(). > > Right, the uploading side I understand, the question is how to get to > them from > the compute kernel's tgsi code ? Right, I...

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans

...as "input" memory. > > "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a > special memory type is added for this, since the actual storage of these > (e.g. UBO-s) may differ per implementation. The uploading of kernel > parameters is handled by launch_grid, "MEMORY[x], INPUT" allows drivers > to use an access mechanism for parameter reads which matches with the > upload method. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > src/gallium/auxiliary/tgsi/tgsi_build.c | 8 +++---- > src/...