search for: pipe_grid_info

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 <hde...

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. &g...

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...

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...

On 03/14/2016 02:29 PM, Samuel Pitoiset wrote: > > > On 03/14/2016 02:26 PM, Hans de Goede 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 >>>> de...

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-o...

On 03/14/2016 02:26 PM, Hans de Goede 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 i...

...uel Pitoiset wrote: >> >> >> On 03/14/2016 02:26 PM, Hans de Goede 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...

...; 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 suggesting to use BUFFER[0] for this, that is fine...

...gt;>> 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 wonder if there is alr...

...ivers/nouveau/nv50/nv50_compute.c b/src/gallium/drivers/nouveau/nv50/nv50_compute.c index d781f6f..3c174e4 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_compute.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_compute.c @@ -249,9 +249,11 @@ nv50_launch_grid(struct pipe_context *pipe, const struct pipe_grid_info *info) struct nv50_program *cp = nv50->compprog; bool ret; + pipe_mutex_lock(nv50->screen->base.push_mutex); ret = !nv50_state_validate_cp(nv50, ~0); if (ret) { NOUVEAU_ERR("Failed to launch grid !\n"); + pipe_mutex_unlock(nv50->screen->base....

...t;>>> 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 ? >> >> Rig...

...tting 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 ? >>...

...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 > the compute kernel's tgsi code ? Right, I wonder if there is already a DECL INPUT or somethin...

Hi, On 19-02-16 20:43, Ilia Mirkin wrote: > On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 18-02-16 17:39, Ilia Mirkin wrote: >>> >>> On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede <hdegoede at redhat.com> >>> wrote: >>>> >>>> But this does not seem to be hooked up

...o 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(). I will have a look at the test_input_global(). Thanks! > > Currently the kernel input parameters are uploaded by > src/gallium/drivers/nouveau/nv50/nv50_compute.c: > nv50_compute_upload_input...