similar to: [RFC] mesa/st: Avoid passing a NULL buffer to the drivers

On 11.01.2015 06:05, Ilia Mirkin wrote: > Can you elaborate a bit as to why that's the right thing to do? > > On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> If we capture transform feedback from n stream in (n-1) buffers we face a >> NULL buffer, use the buffer (n-1) to capture the output of stream n.

On 12.01.2015 01:57, Ilia Mirkin wrote: > On Sun, Jan 11, 2015 at 7:43 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 11.01.2015 06:05, Ilia Mirkin wrote: >>> Can you elaborate a bit as to why that's the right thing to do? >>> >>> On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann >>>

If a transform feedback buffer's size is 0, st_bufferobj_data doesn't end up creating a buffer for it. There's no point in trying to write to such a buffer, so just pretend as if it's not really there. This fixes arb_gpu_shader5-xfb-streams-without-invocations on nvc0. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/mesa/state_tracker/st_cb_xformfb.c | 2 +- 1

On Sun, Jan 11, 2015 at 7:43 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 11.01.2015 06:05, Ilia Mirkin wrote: >> >> Can you elaborate a bit as to why that's the right thing to do? >> >> On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann >> <tobias.johannes.klausmann at mni.thm.de> wrote: >>>

Can you elaborate a bit as to why that's the right thing to do? On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > If we capture transform feedback from n stream in (n-1) buffers we face a > NULL buffer, use the buffer (n-1) to capture the output of stream n. > > This fixes one piglit test with nvc0: >

Hi all, I'm looking for an efficient solution (speed and memory) for the following problem: Given - a data.frame x containing numbers of type double with nrow(x)>ncol(x) and unique row lables and - a character vector y containing a sorted order labels Now, I'd like to sort the rows of the data.frame x w.r.t. the order of labels in y. example: x <- data.frame(c(1:4),c(5:8))

http://bugs.freedesktop.org/show_bug.cgi?id=23505 Summary: KDE's Kubrick has problems with xf86-video-nouveau driver Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at

Dear list, dear Frank, I try to fit a Weibull survival regression model with package Design: sclear <- psm(sobj~V1+V2,dist="weibull") sobj is a one-dimensional survival object (no event indicators), V1 and V2 are factors. I get the following result: Parametric Survival Model: Weibull Distribution psm(formula = sobj ~ V1 + V2, dist = "weibull") Obs Events

Hello all, First of all, thank you for such great software. I have a bug (and a fix) to report for 5.1p: The "Axway XFB.Gateway" SFTP server will drop sftp sessions initiated from the OpenSSH 5.1p (HP-UX) sftp if it receives the "no-more-sessions at openssh.com" flag. It can be reproduced also with the sftp sessions initiated from a OpenSSH 5.1p sftp on a Linux machine. As

Running Tomb Raider on Nouveau I found some flicker caused by ignoring precise modifiers on variables inside Nouveau. This series add precise/invariant handling to TGSI, which can be then used by drivers to disable certain unsafe optimisations which may otherwise alter calculations, which depend on having the same result across shaders. This series fixes this bug in Tomb Raider and one CTS test

--- src/gallium/drivers/nv40/nv40_fragprog.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nv40/nv40_fragprog.c b/src/gallium/drivers/nv40/nv40_fragprog.c index 1237066..209d211 100644 --- a/src/gallium/drivers/nv40/nv40_fragprog.c +++ b/src/gallium/drivers/nv40/nv40_fragprog.c @@ -843,7 +843,8 @@ nv40_fragprog_translate(struct nv40_context *nv40,

Author: cwb Repository: /hg/zfs-crypto/gate Revision: 1363ff405550b8be8cd10a06075ba11178182f35 Log message: 6350363 anon_array_try_enter needs to initialise sobj->sync_cv Files: update: usr/src/uts/common/vm/vm_anon.c

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

This looks like the right idea to me too. It may sound a bit weird to do that per instruction, but d3d11 does that as well. (Some d3d versions just have a global flag basically forbidding or allowing any such fast math optimizations in the assembly, but I'm not actually sure everybody honors that without tesselation...) For 1/9: Reviewed-by: Roland Scheidegger <sroland at vmware.com>

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdegoede at redhat.com> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Changes in v2: -Add Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++++++ 1 file changed, 6

On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Extend the MEMORY file support to differentiate between global, local > and shared memory, as well 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.

On 24.05.2015 20:25, Ilia Mirkin wrote: > I'm having a bit of trouble tracing through this. What happens if I > have a shader that just does: > > gl_ClipDistance[0] = 1; > gl_CullDistance[0] = 1; > > what does the resulting TGSI look like? (Assuming that clip plane 0 is > enabled.) What about the generated nvc0 code (for the vertex shader)? (hack up a patch for this,

Tested with: MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5 ./shader_runner ../tests/spec/arb_gpu_shader5/execution/built-in-functions/fs-bitfieldReverse.shader_test -> green output, so this should be ok the test was not change though... On 29.05.2014 21:47, Ilia Mirkin wrote: > Can you verify that you tested how the HW handles this, as well as > exactly how you did it (i.e. how did you

Backtrace: ... 0x00007ffff57fc392 in __assert_fail () from /lib64/libc.so.6 0x00007ffff0cf5bec in nvc0_shader_stage (pipe=<optimized out>) at ./nvc0/nvc0_context.h:204 nvc0_set_constant_buffer (pipe=0x631080, shader=<optimized out>, index=<optimized out>, cb=0x0) at nvc0/nvc0_state.c:771 0x00007ffff0a2cf63 in st_destroy_context (st=0x68a9f0) at state_tracker/st_context.c:382

Hi All, While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089 I made a apitrace recording of the a single slide transition animation, and since I suspected memory corruption replayed it using ElectrFence + glretrace, this finds a 0 sized array allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565: if (proginfo->Parameters) { t->constants = (struct