search for: radeonsi

...tently in one of the above configuratoins) it's the output that's completely off (some purple-ish thing). As I don't have the hardware myself, I was hoping someone could confirm that this is a nouveau issue and not a more general one. Ideally this would be done by testing VDPAU on both radeonsi and r600, as well as both the DRI3 and the DRI2 paths. Please use mplayer for this, not mpv or mplayer2 or anything else -- all those have various differences in how the rendering is done from mplayer, which could account for a different final result. Thanks, Ilia Mirkin imirkin at alum.mit.edu

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Tested on NVE6. Very strange that it seems to use 8 bits for offsets, vs 4 bits used by texelFetch. But this passes the piglit tests. Will test on a NVCX before checking in, in case it's different there. (Although that'd be surprising, given the similarities between the 2 ISAs.)

...src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/radeonsi_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 3 ++- 14 files changed, 17 insertions(+), 1 deletion(-) diff --git a/src/gallium/docs/source/screen.rst b/s...

...c | 1 + >> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >> src/gallium/drivers/r300/r300_screen.c | 1 + >> src/gallium/drivers/r600/r600_pipe.c | 1 + >> src/gallium/drivers/radeonsi/radeonsi_pipe.c | 1 + >> src/gallium/drivers/softpipe/sp_screen.c | 1 + >> src/gallium/drivers/svga/svga_screen.c | 1 + >> src/gallium/include/pipe/p_defines.h | 3 ++- >> 14 files changed, 17 insertions(+), 1 deletion(-) >> >&gt...

Ilia Mirkin wrote: > As I don't have the hardware myself, I was hoping someone could > confirm that this is a nouveau issue and not a more general one. > Ideally this would be done by testing VDPAU on both radeonsi and r600, > as well as both the DRI3 and the DRI2 paths. Please use mplayer for > this, not mpv or mplayer2 or anything else -- all those have various > differences in how the rendering is done from mplayer, which could > account for a different final result. Current svn mplayer + git...

...cs/GL3.txt b/docs/GL3.txt > index d9cc708..bf51e3a 100644 > --- a/docs/GL3.txt > +++ b/docs/GL3.txt > @@ -107,7 +107,7 @@ GL 4.0: > GL_ARB_tessellation_shader not started > GL_ARB_texture_buffer_object_rgb32 DONE (i965, nvc0, r600, radeonsi, softpipe) > GL_ARB_texture_cube_map_array DONE (i965, nv50, nvc0, r600, softpipe) > - GL_ARB_texture_gather DONE (i965, nv50) > + GL_ARB_texture_gather DONE (i965, nv50, nvc0) Do you also want to ad...

...au/nv30/nv30_screen.c | 1 + > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + > src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + > src/gallium/drivers/r300/r300_screen.c | 1 + > src/gallium/drivers/r600/r600_pipe.c | 1 + > src/gallium/drivers/radeonsi/radeonsi_pipe.c | 1 + > src/gallium/drivers/softpipe/sp_screen.c | 1 + > src/gallium/drivers/svga/svga_screen.c | 1 + > src/gallium/include/pipe/p_defines.h | 3 ++- > 14 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/src/galli...

...t; src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >>> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >>> src/gallium/drivers/r300/r300_screen.c | 1 + >>> src/gallium/drivers/r600/r600_pipe.c | 1 + >>> src/gallium/drivers/radeonsi/radeonsi_pipe.c | 1 + >>> src/gallium/drivers/softpipe/sp_screen.c | 1 + >>> src/gallium/drivers/svga/svga_screen.c | 1 + >>> src/gallium/include/pipe/p_defines.h | 3 ++- >>> 14 files changed, 17 insertions(+), 1 deletion(-)...

...1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index d9cc708..bf51e3a 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -107,7 +107,7 @@ GL 4.0: GL_ARB_tessellation_shader not started GL_ARB_texture_buffer_object_rgb32 DONE (i965, nvc0, r600, radeonsi, softpipe) GL_ARB_texture_cube_map_array DONE (i965, nv50, nvc0, r600, softpipe) - GL_ARB_texture_gather DONE (i965, nv50) + GL_ARB_texture_gather DONE (i965, nv50, nvc0) GL_ARB_transform_feedback2...

Hi, On 22-04-16 09:08, Marek Olšák wrote: > On Thu, Apr 21, 2016 at 7:04 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> [+radeon folk] >> >> Marek, Nicolai, Bas - please have a look at the doc change and let us >> know if you think this will cause a problem for radeon. >> >> Hans is solving the issue that he wants to swizzle the data loaded

...dling 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. > > It's kind of amazing that we got this far without doing this. On the > radeonsi side, it's probably related to how conservative LLVM is. > > But this series is a good idea, since it might allow us to become more > aggressive with optimizations in radeonsi as well. > > >> This series fixes this bug in Tomb Raider and one CTS test for 4.4 and >>...

...eries 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. It's kind of amazing that we got this far without doing this. On the radeonsi side, it's probably related to how conservative LLVM is. But this series is a good idea, since it might allow us to become more aggressive with optimizations in radeonsi as well. > This series fixes this bug in Tomb Raider and one CTS test for 4.4 and 4.5 > > Note on Patch 3: I re...

...:54 PM, Andy Furniss <adf.lists at gmail.com> wrote: > Ilia Mirkin wrote: > >> As I don't have the hardware myself, I was hoping someone could >> confirm that this is a nouveau issue and not a more general one. >> Ideally this would be done by testing VDPAU on both radeonsi and r600, >> as well as both the DRI3 and the DRI2 paths. Please use mplayer for >> this, not mpv or mplayer2 or anything else -- all those have various >> differences in how the rendering is done from mplayer, which could >> account for a different final result. > > &...

...e to libreoffice doing something opengl >> related differently then glretrace, be it the visual or something else >> back buffer related ... >> > > Does libreoffice use llvm? I have vague recollections of there being > issues with llvm and libreoffice in the past because radeonsi uses > llvm as well. FWIW the nv30 gallium driver will only use llvm as part of 'draw' when falling back to the swtnl path. This should be extremely rare. But easy enough to build mesa with --disable-gallium-llvm to double-check (or what was the env var? DRAW_USE_LLVM=0 or something alo...

...n be then >>> used by >>> drivers to disable certain unsafe optimisations which may otherwise alter >>> calculations, which depend on having the same result across shaders. >> >> It's kind of amazing that we got this far without doing this. On the >> radeonsi side, it's probably related to how conservative LLVM is. >> >> But this series is a good idea, since it might allow us to become more >> aggressive with optimizations in radeonsi as well. >> >> >>> This series fixes this bug in Tomb Raider and one CTS test...

Hi! I'm trying to run Blender using Mesa OpenCL implementation on a radeonsi card. First the kernel didn't want to compile, but that was caused by a bug in it (they were using . instead of -> in 1 place), and after fixing this bug I've got the kernel to compile... ...But after that, LLVM started to crash during translation of IR into shader code with R60...

On 05/07/2018 12:28 AM, Nicolai Hähnle via llvm-dev wrote: > We have a similar problem in Mesa's radeonsi driver. It would be great if command-line options could somehow be tied to an llvm::Context, for example. > > There is an even worse problem when *different versions* of LLVM are loaded into the same process. This is basically guaranteed to lead to crashes because of symbol clashes. I wonder...

https://bugs.freedesktop.org/show_bug.cgi?id=95190 Bug ID: 95190 Summary: Tomb Raider with PostProcessing enable and Depth of Field set to Ultra has white stuff in the foreground Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium

The main patches are from Christoph. Unfortunately they're a little beyond my understanding of all the vertex-related details, but they generally seemed fine. I'm just going to push these unless someone steps up to review them. Christoph Bumiller (2): nvc0: add support for indirect drawing nvc0: fix translate path for PRIM_RESTART_WITH_DRAW_ARRAYS Ilia Mirkin (1): nouveau: check if

...>> related differently then glretrace, be it the visual or something else >>>> back buffer related ... >>>> >>> >>> Does libreoffice use llvm? I have vague recollections of there being >>> issues with llvm and libreoffice in the past because radeonsi uses >>> llvm as well. >> >> >> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when >> falling back to the swtnl path. This should be extremely rare. But >> easy enough to build mesa with --disable-gallium-llvm to double-check >&g...