Re: [Mesa-dev] [PATCHES] Tessellation is here
Am 17.06.2015 14:34, schrieb Marek Olšák: Only the RadeonSI driver supports it right now. Marek Marek, will we ever see something on r600 or do we need 'new' boards (Turks, here)? GREAT stuff. -Dieter On Wed, Jun 17, 2015 at 2:21 PM, Ilyes Gouta wrote: Hi, On Wed, Jun 17, 2015 at 1:03 PM, Dragomir Ivanov wrote: Wonderful Marek. Many thanks to you all. I hope till the end of the year we will have OGL 4.3 in Mesa. Is LLVMpipe (and software rasterziation) also supported? Ilyes On Wed, Jun 17, 2015 at 2:18 AM, Marek Olšák wrote: You can also use this for nicer reviewing: http://cgit.freedesktop.org/~mareko/mesa/log/?h=tessellation-review Please note that there are differences from Chris Forbes's tessellation branches. I think I modified almost all patches when I was reviewing them, fixing them, and cleaning them up. Marek On Wed, Jun 17, 2015 at 1:00 AM, Marek Olšák wrote: > Hi, > > First, I'd like to thank Fabian Bieler, Chris Forbes, and Ilia Mirkin > for their contributions to this. > > The development of tessellation has reached the point that the only > way to make it better and more compliant is to write piglit tests that > help find small bugs that are difficult to catch during code review. > According to piglit, it's already more compliant than the NVIDIA > driver. (The NVIDIA GLSL compiler sometimes even dies with an internal > error on some of the variable indexing tests. I haven't tested > Catalyst.) > > Other than piglit, the following apps have been tested: > - Unigine Heaven 4.0 (wireframe both on and off) > - TessMark 0.3.0 * > - GpuTest 0.7.0 containing a newer version of TessMark * > - Tutorials 30 and 31 from http://ogldev.atspace.co.uk/ * > > (* These don't work with the OpenGL Core profile and need overrides > and code hacks to enable OpenGL 4.0 Compatibility) > > The RadeonSI driver support is complete and requires LLVM 3.6.2. There > is just one small bug with GpuTest 0.7.0. > > The patches will be split up into 3 series: > 1) Mesa + GLSL > 2) State tracker > 3) Radeonsi > > docs/GL3.txt | 2 +- > docs/relnotes/10.7.0.html | 1 + > src/gallium/docs/source/screen.rst| 4 + > src/gallium/drivers/freedreno/freedreno_screen.c | 1 + > src/gallium/drivers/i915/i915_screen.c| 1 + > src/gallium/drivers/ilo/ilo_screen.c | 1 + > src/gallium/drivers/llvmpipe/lp_screen.c | 1 + > 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/radeon/r600_pipe_common.c | 6 + > src/gallium/drivers/radeon/r600_pipe_common.h | 20 +- > src/gallium/drivers/radeon/radeon_llvm.h | 14 +- > src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 + > .../drivers/radeon/radeon_setup_tgsi_llvm.c | 40 +- > src/gallium/drivers/radeonsi/si_blit.c| 2 + > src/gallium/drivers/radeonsi/si_descriptors.c | 251 -- > src/gallium/drivers/radeonsi/si_hw_context.c | 8 + > src/gallium/drivers/radeonsi/si_pipe.c| 22 +- > src/gallium/drivers/radeonsi/si_pipe.h| 29 +- > src/gallium/drivers/radeonsi/si_shader.c | 835 > ++-- > src/gallium/drivers/radeonsi/si_shader.h | 123 ++- > src/gallium/drivers/radeonsi/si_state.c | 47 +- > src/gallium/drivers/radeonsi/si_state.h | 23 +- > src/gallium/drivers/radeonsi/si_state_draw.c | 217 - > src/gallium/drivers/radeonsi/si_state_shaders.c | 494 +++- > src/gallium/drivers/softpipe/sp_screen.c | 1 + > src/gallium/drivers/svga/svga_screen.c| 1 + > src/gallium/drivers/vc4/vc4_screen.c | 1 + > src/gallium/include/pipe/p_defines.h | 1 + > src/glsl/Makefile.sources | 1 + > src/glsl/ast.h| 55 +- > src/glsl/ast_array_index.cpp | 47 +- > src/glsl/ast_to_hir.cpp | 350 +++- > src/glsl/ast_type.cpp | 115 ++- > src/glsl/builtin_functions.cpp| 4 +- > src/glsl/builtin_variables.cpp| 112 ++- > src/glsl/glcpp/glcpp-parse.y | 3 + > src/glsl/glsl_lexer.ll| 5 +- > src/glsl/glsl_parser.yy | 133 +++- > src/glsl/glsl_parser_extras.cpp | 60 +- > src/glsl/glsl_parser_extras.h | 48 +- > src/glsl/glsl_types.cpp | 5 + > src/glsl/glsl_types.h | 6 + > src/glsl/ir.cpp |
Re: [Mesa-dev] [PATCH 2/2] gbm: Add flags to enable creation of rotated scanout buffers (v4)
Am 07.11.2015 04:05, schrieb Vivek Kasireddy:
For certain platforms that support rotated scanout buffers, currently,
there is no way to create them with the GBM DRI interface. These flags
will instruct the DRI driver to create the buffer by setting
additional requirements such as tiling mode.
v2: Reserve a bit per angle. (Ville and Michel)
v3:
- Combine all GBM_BO_USE_SCANOUT_ROTATION_* flags into
GBM_BO_USE_SCANOUT_ANY macro (Michel)
- Pull the code that updates dri_use based on the rotation flag
into a separate function.
v4:
- Added a brief comment to explain the rotation orientation.
- Augmented the helper function gbm_to_dri_flag() introduced in v3
to handle GBM_BO_USE_CURSOR and GBM_BO_USE_LINEAR as well. (Michel)
Cc: Michel Danzer
Cc: Ville Syrjala
Signed-off-by: Vivek Kasireddy
---
src/gbm/backends/dri/gbm_dri.c | 35
+++
src/gbm/main/gbm.h | 15 +++
2 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c
b/src/gbm/backends/dri/gbm_dri.c
index 57cdeac..6616d37 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -124,6 +124,24 @@ image_get_buffers(__DRIdrawable *driDrawable,
}
static void
+gbm_to_dri_flag(uint32_t usage,
+unsigned *dri_use)
+{
+ if (usage & GBM_BO_USE_SCANOUT)
+ *dri_use |= __DRI_IMAGE_USE_SCANOUT;
+ if (usage & GBM_BO_USE_SCANOUT_ROTATION_90)
+ *dri_use |= __DRI_IMAGE_USE_SCANOUT_ROTATION_90;
+ if (usage & GBM_BO_USE_SCANOUT_ROTATION_180)
+ *dri_use |= __DRI_IMAGE_USE_SCANOUT_ROTATION_180;
+ if (usage & GBM_BO_USE_SCANOUT_ROTATION_270)
+ *dri_use |= __DRI_IMAGE_USE_SCANOUT_ROTATION_270;
+ if (usage & GBM_BO_USE_CURSOR)
+ *dri_use |= __DRI_IMAGE_USE_CURSOR;
+ if (usage & GBM_BO_USE_LINEAR)
+ *dri_use |= __DRI_IMAGE_USE_LINEAR;
+}
+
+static void
swrast_get_drawable_info(__DRIdrawable *driDrawable,
int *x,
int *y,
@@ -539,7 +557,7 @@ gbm_dri_is_format_supported(struct gbm_device *gbm,
break;
case GBM_BO_FORMAT_ARGB:
case GBM_FORMAT_ARGB:
- if (usage & GBM_BO_USE_SCANOUT)
+ if (usage & GBM_BO_USE_SCANOUT_ANY)
return 0;
break;
default:
@@ -746,10 +764,8 @@ gbm_dri_bo_import(struct gbm_device *gbm,
bo->image = image;
- if (usage & GBM_BO_USE_SCANOUT)
- dri_use |= __DRI_IMAGE_USE_SCANOUT;
- if (usage & GBM_BO_USE_CURSOR)
- dri_use |= __DRI_IMAGE_USE_CURSOR;
+ gbm_to_dri_flag(usage, &dri_use);
+
if (dri->image->base.version >= 2 &&
!dri->image->validateUsage(bo->image, dri_use)) {
errno = EINVAL;
@@ -786,7 +802,7 @@ create_dumb(struct gbm_device *gbm,
is_cursor = (usage & GBM_BO_USE_CURSOR) != 0 &&
format == GBM_FORMAT_ARGB;
- is_scanout = (usage & GBM_BO_USE_SCANOUT) != 0 &&
+ is_scanout = (usage & GBM_BO_USE_SCANOUT_ANY) != 0 &&
format == GBM_FORMAT_XRGB;
if (!is_cursor && !is_scanout) {
errno = EINVAL;
@@ -878,12 +894,7 @@ gbm_dri_bo_create(struct gbm_device *gbm,
goto failed;
}
- if (usage & GBM_BO_USE_SCANOUT)
- dri_use |= __DRI_IMAGE_USE_SCANOUT;
- if (usage & GBM_BO_USE_CURSOR)
- dri_use |= __DRI_IMAGE_USE_CURSOR;
- if (usage & GBM_BO_USE_LINEAR)
- dri_use |= __DRI_IMAGE_USE_LINEAR;
+ gbm_to_dri_flag(usage, &dri_use);
/* Gallium drivers requires shared in order to get the
handle/stride */
dri_use |= __DRI_IMAGE_USE_SHARE;
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 8db2153..667fcf7 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -214,8 +214,23 @@ enum gbm_bo_flags {
* Buffer is linear, i.e. not tiled.
*/
GBM_BO_USE_LINEAR = (1 << 4),
+ /**
+* Buffer would be rotated and some platforms have additional
tiling
+* requirements for rotated scanout buffers.
+* And, setting a rotation angle of 90 or 270 would result in the
+* scanout buffer being rotated in a clounter clockwise manner.
This
Spelling: ...counter...
Greetings,
Dieter
+* is the expected behavior for ensuring XRandR compliance.
+*/
+ GBM_BO_USE_SCANOUT_ROTATION_90 = (1 << 5),
+ GBM_BO_USE_SCANOUT_ROTATION_180 = (1 << 6),
+ GBM_BO_USE_SCANOUT_ROTATION_270 = (1 << 7),
};
+#define GBM_BO_USE_SCANOUT_ANY (GBM_BO_USE_SCANOUT | \
+GBM_BO_USE_SCANOUT_ROTATION_90 | \
+GBM_BO_USE_SCANOUT_ROTATION_180 | \
+GBM_BO_USE_SCANOUT_ROTATION_270)
+
int
gbm_device_get_fd(struct gbm_device *gbm);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't enable NV_fragment_program_option with swrast
Am 16.02.2015 18:13, schrieb Brian Paul: On 02/16/2015 08:11 AM, Roland Scheidegger wrote: Am 16.02.2015 um 00:36 schrieb Matt Turner: On Sat, Feb 14, 2015 at 2:33 PM, Roland Scheidegger wrote: Am 14.02.2015 um 21:12 schrieb Kenneth Graunke: On Saturday, February 14, 2015 04:37:25 PM srol...@vmware.com wrote: From: Roland Scheidegger Since dropping some NV_fragment_program opcodes (commits 868f95f1da74cf6dd7468cba1b56664aad585ccb, a3688d686f147f4252d19b298ae26d4ac72c2e08) we can no longer parse all opcodes necessary for this extension, leading to bugs (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D86980&d=AwICAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=WR7M0CMoTs3KQMrLGbBd33mSg7pYv21Om0yOzq27Swg&s=VVYgQUmxDRQ8b-H-36lfDVGUw4SFuqAVM1qfxbB71pc&e= ). Hence don't announce support for it in swrast. (The rest of the infrastructure ranging from dead opcodes (TXP_NV) to parsing condition codes along with the NV_fragment_program_option variable in the context could probably nuked too this is just a minimal fix appropriate for stable too.) --- src/mesa/main/extensions.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c index 220b220..c94009f 100644 --- a/src/mesa/main/extensions.c +++ b/src/mesa/main/extensions.c @@ -511,7 +511,6 @@ _mesa_enable_sw_extensions(struct gl_context *ctx) ctx->Extensions.NV_point_sprite = GL_TRUE; ctx->Extensions.NV_texture_env_combine4 = GL_TRUE; ctx->Extensions.NV_texture_rectangle = GL_TRUE; - ctx->Extensions.NV_fragment_program_option = GL_TRUE; ctx->Extensions.EXT_gpu_program_parameters = GL_TRUE; ctx->Extensions.OES_standard_derivatives = GL_TRUE; ctx->Extensions.TDFX_texture_compression_FXT1 = GL_TRUE; Nuking this extension would make some compiler work I'm planning to do easier, so I'd definitely be interested to hear whether you still need it. Well, according to the git log specviewperf11 catia test won't run correctly without supporting some bits from NV_program_option and NV_fragment_program2 - obviously the benchmark doesn't care one bit if the extension is actually officially supported by a driver or not. Just to clarify, this is because the viewperf tests are basically application traces which get replayed, and unfortunately, viewperf doesn't even bother to check if the OpenGL driver supports the extensions which are used by the trace. The traces were created with nvidia drivers. I suspect this is something which we still need to be able to run, though Brian would probably know the definitive answer. If we knew specifically what it uses, maybe we can just support that instead of the whole extension? Not having to handle the condition code bits of the extension would be nice, for instance. There's definitely some bits around condition codes with IF/ELSE/ENDIF needed (with NV_fp2/NV_vp3 even), though it seems there's some differences to our private code there to make it work. Apart from that I'm not entirely sure. Maybe we could expose it as an ordinary quirk to make things more obvious but I've never dealt with that viewperf issue. Here's an example of a fragment program from the catia-03 #3 test: !!ARBfp1.0 OPTION NV_fragment_program2; # cgc version 1.5.0023, build date Sep 26 2007 08:51:03 # command line args: #vendor NVIDIA Corporation #version 1.5.0.23 #profile fp40 #program AdvancedHighlightPS #semantic AdvancedHighlightPS.iOutlineColor #semantic AdvancedHighlightPS.iHaloSize #semantic AdvancedHighlightPS.iHaloIntensity #semantic AdvancedHighlightPS.iHaloColor #semantic AdvancedHighlightPS.iScanEffectIntensity #semantic AdvancedHighlightPS.iScanEffectColor #semantic AdvancedHighlightPS.iInputTexture #semantic outlineColor #semantic haloColor #semantic haloIntensity #semantic haloSize #semantic scanEffectColor #semantic scanEffectIntensity #semantic inputTexture #semantic filterBlurData #semantic filterBlurDataLow #var float4 IN.ScreenPosition : $vin.TEXCOORD0 : TEX0 : 0 : 1 #var float4 iOutlineColor : : c[0] : 1 : 1 #var float iHaloSize : : c[1] : 2 : 1 #var float iHaloIntensity : : c[2] : 3 : 1 #var float4 iHaloColor : : c[3] : 4 : 1 #var float iScanEffectIntensity : : : 5 : 0 #var float4 iScanEffectColor : : c[4] : 6 : 1 #var samplerRECT iInputTexture : : texunit 0 : 7 : 1 #var float4 outlineColor : : : -1 : 0 #var float4 haloColor : : : -1 : 0 #var float haloIntensity : : : -1 : 0 #var float haloSize : : : -1 : 0 #var float4 scanEffectColor : : : -1 : 0 #var float scanEffectIntensity : : : -1 : 0 #var samplerRECT inputTexture : : : -1 : 0 #var float2 filterBlurData[0] : : c[5] : -1 : 1 #var float2 filterBlurData[1] : : c[6] : -1 : 1 #var float2 filterBlurData[2] : : c[7] : -1 : 1 #var float2 filterBlurData[3] : : c[8] : -1 : 1 #var float2 filterBlurData[4] : : c[9] : -1 : 1 #var float2 filterBlurData[5
[Mesa-dev] nir: Compilation error in nir/nir_to_ssa.c
make[3]: Entering directory '/opt/mesa/src/glsl' CC nir/nir_to_ssa.lo In file included from nir/../glsl_types.h:30:0, from nir/nir_types.h:32, from nir/nir.h:36, from nir/nir_to_ssa.c:28: nir/nir_to_ssa.c: In function 'rewrite_def_forwards': nir/nir_to_ssa.c:226:60: error: 'reg_state' has no member named 'stack_size' assert(state->states[index].index < state->states[index].stack_size); ^ Makefile:1602: recipe for target 'nir/nir_to_ssa.lo' failed make[3]: *** [nir/nir_to_ssa.lo] Error 1 It's only defined for DEBUG. -Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl
Hello Michel, as this is for radeon, do you think this could/should fix the wrong reported VRAM size with Unigine_Heaven/-Valley, too? Maybe speed things up? ;-) Unigine_Valley-1.0 GPU: Unknown GPU x1 System memory: 24102 MB Video memory: 256 MB Sync threads: 7 Async threads: 8 I'll try patching openSUSE Kernel:stable 4.9.6-2 with this and maybe this could then go into 4.10-rc7 'cause it is a bugfix. - Alex? Greetings, Dieter Am 31.01.2017 07:54, schrieb Michel Dänzer: From: Michel Dänzer vram_size is supposed to be the total amount of VRAM that can be used by userspace, which corresponds to the TTM VRAM manager size (which is normally the full amount of VRAM, but can be just the visible VRAM when DMA can't be used for BO migration for some reason). The above was incorrectly used for vram_visible before, resulting in generally too large values being reported. Signed-off-by: Michel Dänzer --- drivers/gpu/drm/radeon/radeon_drv.c | 3 ++- drivers/gpu/drm/radeon/radeon_gem.c | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index a252bc407aa2..88c41d43ec3d 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -97,9 +97,10 @@ * 2.46.0 - Add PFP_SYNC_ME support on evergreen * 2.47.0 - Add UVD_NO_OP register support * 2.48.0 - TA_CS_BC_BASE_ADDR allowed on SI + * 2.49.0 - DRM_RADEON_GEM_INFO ioctl returns correct vram_size/visible values */ #define KMS_DRIVER_MAJOR 2 -#define KMS_DRIVER_MINOR 48 +#define KMS_DRIVER_MINOR 49 #define KMS_DRIVER_PATCHLEVEL 0 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags); int radeon_driver_unload_kms(struct drm_device *dev); diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 0bcffd8a7bd3..96683f5b2b1b 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -220,8 +220,8 @@ int radeon_gem_info_ioctl(struct drm_device *dev, void *data, man = &rdev->mman.bdev.man[TTM_PL_VRAM]; - args->vram_size = rdev->mc.real_vram_size; - args->vram_visible = (u64)man->size << PAGE_SHIFT; + args->vram_size = (u64)man->size << PAGE_SHIFT; + args->vram_visible = rdev->mc.visible_vram_size; args->vram_visible -= rdev->vram_pin_size; args->gart_size = rdev->mc.gtt_size; args->gart_size -= rdev->gart_pin_size; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl
Am 31.01.2017 16:43, schrieb Deucher, Alexander: -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Dieter Nützel Sent: Tuesday, January 31, 2017 6:25 AM To: Michel Dänzer Cc: Alex Deucher; mesa-dev@lists.freedesktop.org; amd- g...@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH] drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl Hello Michel, as this is for radeon, do you think this could/should fix the wrong reported VRAM size with Unigine_Heaven/-Valley, too? Maybe speed things up? ;-) Unigine_Valley-1.0 GPU: Unknown GPU x1 System memory: 24102 MB Video memory: 256 MB Sync threads: 7 Async threads: 8 I'll try patching openSUSE Kernel:stable 4.9.6-2 with this and maybe this could then go into 4.10-rc7 'cause it is a bugfix. - Alex? This patch just fixes the case of the HUD reporting the wrong amount of visible vram. Most 3D apps just default to 256MB if they don't know how much vram is. The problem is GL never provided a core way to determine how much vram is available on a GPU so lots of vendor specific extensions and driver specific methods popped up to address this. Alex Ah, no hurry then. Thanks for clarification. Dieter Greetings, Dieter Am 31.01.2017 07:54, schrieb Michel Dänzer: > From: Michel Dänzer > > vram_size is supposed to be the total amount of VRAM that can be used > by > userspace, which corresponds to the TTM VRAM manager size (which is > normally the full amount of VRAM, but can be just the visible VRAM when > DMA can't be used for BO migration for some reason). > > The above was incorrectly used for vram_visible before, resulting in > generally too large values being reported. > > Signed-off-by: Michel Dänzer > --- > drivers/gpu/drm/radeon/radeon_drv.c | 3 ++- > drivers/gpu/drm/radeon/radeon_gem.c | 4 ++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c > b/drivers/gpu/drm/radeon/radeon_drv.c > index a252bc407aa2..88c41d43ec3d 100644 > --- a/drivers/gpu/drm/radeon/radeon_drv.c > +++ b/drivers/gpu/drm/radeon/radeon_drv.c > @@ -97,9 +97,10 @@ > * 2.46.0 - Add PFP_SYNC_ME support on evergreen > * 2.47.0 - Add UVD_NO_OP register support > * 2.48.0 - TA_CS_BC_BASE_ADDR allowed on SI > + * 2.49.0 - DRM_RADEON_GEM_INFO ioctl returns correct > vram_size/visible values > */ > #define KMS_DRIVER_MAJOR 2 > -#define KMS_DRIVER_MINOR 48 > +#define KMS_DRIVER_MINOR 49 > #define KMS_DRIVER_PATCHLEVEL 0 > int radeon_driver_load_kms(struct drm_device *dev, unsigned long > flags); > int radeon_driver_unload_kms(struct drm_device *dev); > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c > b/drivers/gpu/drm/radeon/radeon_gem.c > index 0bcffd8a7bd3..96683f5b2b1b 100644 > --- a/drivers/gpu/drm/radeon/radeon_gem.c > +++ b/drivers/gpu/drm/radeon/radeon_gem.c > @@ -220,8 +220,8 @@ int radeon_gem_info_ioctl(struct drm_device *dev, > void *data, > >man = &rdev->mman.bdev.man[TTM_PL_VRAM]; > > - args->vram_size = rdev->mc.real_vram_size; > - args->vram_visible = (u64)man->size << PAGE_SHIFT; > + args->vram_size = (u64)man->size << PAGE_SHIFT; > + args->vram_visible = rdev->mc.visible_vram_size; >args->vram_visible -= rdev->vram_pin_size; >args->gart_size = rdev->mc.gtt_size; >args->gart_size -= rdev->gart_pin_size; ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g/sb: Fix memory leak by reworking uses list
Am 07.02.2017 22:30, schrieb Heiko Przybyl:
When fixing the stalls on evergreen I introduced leaking of the useinfo
structure(s). Sorry. Instead of allocating a new object to hold 3
values
where only one is actually used, rework the list to just store the node
pointer. Thus no allocating and deallocation is needed. Since use_info
and use_kind aren't used anywhere, drop them and reduce code
complexity.
This might also save some small amount of cycles.
Thanks to Bartosz Tomczyk for finding the bug.
Reported-by: Bartosz Tomczyk
Signed-off-by: Heiko Przybyl
Supersedes: https://patchwork.freedesktop.org/patch/135852
---
src/gallium/drivers/r600/sb/sb_def_use.cpp | 29
+++--
src/gallium/drivers/r600/sb/sb_gcm.cpp | 16
src/gallium/drivers/r600/sb/sb_ir.h | 23
++-
src/gallium/drivers/r600/sb/sb_valtable.cpp | 13 ++---
4 files changed, 27 insertions(+), 54 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_def_use.cpp
b/src/gallium/drivers/r600/sb/sb_def_use.cpp
index a512d92086..68ab4ca26c 100644
--- a/src/gallium/drivers/r600/sb/sb_def_use.cpp
+++ b/src/gallium/drivers/r600/sb/sb_def_use.cpp
@@ -106,58 +106,51 @@ void def_use::process_defs(node *n, vvec &vv,
bool arr_def) {
}
void def_use::process_uses(node* n) {
- unsigned k = 0;
-
- for (vvec::iterator I = n->src.begin(), E = n->src.end(); I != E;
- ++I, ++k) {
+ for (vvec::iterator I = n->src.begin(), E = n->src.end(); I != E;
++I) {
value *v = *I;
if (!v || v->is_readonly())
continue;
if (v->is_rel()) {
if (!v->rel->is_readonly())
- v->rel->add_use(n, UK_SRC_REL, k);
+ v->rel->add_use(n);
- unsigned k2 = 0;
for (vvec::iterator I = v->muse.begin(), E =
v->muse.end();
- I != E; ++I, ++k2) {
+ I != E; ++I) {
value *v = *I;
if (!v)
continue;
- v->add_use(n, UK_MAYUSE, k2);
+ v->add_use(n);
}
} else
- v->add_use(n, UK_SRC, k);
+ v->add_use(n);
}
- k = 0;
- for (vvec::iterator I = n->dst.begin(), E = n->dst.end(); I != E;
- ++I, ++k) {
+ for (vvec::iterator I = n->dst.begin(), E = n->dst.end(); I != E;
++I) {
value *v = *I;
if (!v || !v->is_rel())
continue;
if (!v->rel->is_readonly())
- v->rel->add_use(n, UK_DST_REL, k);
- unsigned k2 = 0;
+ v->rel->add_use(n);
for (vvec::iterator I = v->muse.begin(), E = v->muse.end();
- I != E; ++I, ++k2) {
+ I != E; ++I) {
value *v = *I;
if (!v)
continue;
- v->add_use(n, UK_MAYDEF, k2);
+ v->add_use(n);
}
}
if (n->pred)
- n->pred->add_use(n, UK_PRED, 0);
+ n->pred->add_use(n);
if (n->type == NT_IF) {
if_node *i = static_cast(n);
if (i->cond)
- i->cond->add_use(i, UK_COND, 0);
+ i->cond->add_use(i);
}
}
diff --git a/src/gallium/drivers/r600/sb/sb_gcm.cpp
b/src/gallium/drivers/r600/sb/sb_gcm.cpp
index 9c75389ada..7b43a32818 100644
--- a/src/gallium/drivers/r600/sb/sb_gcm.cpp
+++ b/src/gallium/drivers/r600/sb/sb_gcm.cpp
@@ -200,27 +200,27 @@ void gcm::td_release_val(value *v) {
);
for (uselist::iterator I = v->uses.begin(), E = v->uses.end(); I !=
E; ++I) {
- use_info *u = *I;
- if (u->op->parent != &pending) {
+ node *op = *I;
+ if (op->parent != &pending) {
continue;
}
GCM_DUMP(
sblog << "tdused in ";
- dump::dump_op(u->op);
+ dump::dump_op(op);
sblog << "\n";
);
- assert(uses[u->op] > 0);
- if (--uses[u->op] == 0) {
+ assert(uses[op] > 0);
+ if (--uses[op] == 0) {
GCM_DUMP(
sblog << "tdreleased : ";
- dump::dump_op(u->op);
+ dump::dump_op(op);
sblog << "\n";
);
-
[Mesa-dev] Mesa git: compilation error in NINE after your latest commit - 'PIPE_CAP_USER_INDEX_BUFFERS' undeclared
Making all in state_trackers/nine make[4]: Entering directory '/opt/mesa/src/gallium/state_trackers/nine' CC device9.lo device9.c: In function 'NineDevice9_ctor': device9.c:122:49: error: 'PIPE_CAP_USER_INDEX_BUFFERS' undeclared (first use in this function) #define GET_PCAP(n) pScreen->get_param(pScreen, PIPE_CAP_##n) ^ device9.c:476:36: note: in expansion of macro 'GET_PCAP' This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) && !This->csmt_active; ^ device9.c:122:49: note: each undeclared identifier is reported only once for each function it appears in #define GET_PCAP(n) pScreen->get_param(pScreen, PIPE_CAP_##n) ^ device9.c:476:36: note: in expansion of macro 'GET_PCAP' This->driver_caps.user_ibufs = GET_PCAP(USER_INDEX_BUFFERS) && !This->csmt_active; ^ Makefile:745: recipe for target 'device9.lo' failed make[4]: *** [device9.lo] Error 1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: add support for an on-disk shader cache
Am 25.02.2017 05:56, schrieb Timothy Arceri:
On 24/02/17 21:02, Marek Olšák wrote:
On Fri, Feb 24, 2017 at 3:18 AM, Timothy Arceri
wrote:
On 24/02/17 08:49, Timothy Arceri wrote:
On 24/02/17 05:12, Marek Olšák wrote:
On Thu, Feb 23, 2017 at 3:09 AM, Timothy Arceri
wrote:
From: kdj0c
V2 (Timothy Arceri):
- when loading from disk cache also binary insert into memory
cache.
- check that the binary loaded from disk is the correct size. If
not
delete the cache item and skip loading from cache.
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 69
++---
1 file changed, 62 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index f615aa8..71556f9 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -36,6 +36,9 @@
#include "util/u_memory.h"
#include "util/u_prim.h"
+#include "util/disk_cache.h"
+#include "util/mesa-sha1.h"
+
/* SHADER_CACHE */
/**
@@ -182,10 +185,12 @@ static bool si_load_shader_binary(struct
si_shader *shader, void *binary)
*/
static bool si_shader_cache_insert_shader(struct si_screen
*sscreen,
void *tgsi_binary,
- struct si_shader
*shader)
+ struct si_shader
*shader,
+ bool
insert_into_disk_cache)
{
void *hw_binary;
struct hash_entry *entry;
+ uint8_t key[CACHE_KEY_SIZE];
entry = _mesa_hash_table_search(sscreen->shader_cache,
tgsi_binary);
if (entry)
@@ -201,6 +206,12 @@ static bool
si_shader_cache_insert_shader(struct
si_screen *sscreen,
return false;
}
+ if (sscreen->b.disk_shader_cache &&
insert_into_disk_cache) {
+ _mesa_sha1_compute(tgsi_binary, *((uint32_t
*)tgsi_binary), key);
What happens if we randomly get a sha1 collision?
You should stop playing your game which will be rendering
incorrectly
and by a lotto ticket.
Shouldn't we store the whole key as well?
Sure I can add that, its cheap to check here anyway. Although the
other
cache stages rely on a collision being improbable.
For some reason I thought the key was simpler than it is. It seems
excessive
to store and compare the tgsi again. I don't think git even worries
about
the possibility of a collision and we will be dealing with much
smaller
amounts of cache items then commits in a git repository.
Thoughts?
I'll let others comment on this. If nobody comments, checking only the
key can stay.
Seems SVN didn't used to worry about collisions either.
https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/
Shouldn't sha1 _completely_ avoided, then?
Greetings,
Dieter
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [r600g] Mesa git: undefined reference to `ac_shader_binary_config_start' and `ac_elf_read'
Hello Timothy, after your latest commit I get this: make[4]: Entering directory '/opt/mesa/src/gallium/targets/pipe-loader' CXXLDpipe_r600.la ../../../../src/gallium/drivers/r600/.libs/libr600.a(evergreen_compute.o): In function `r600_shader_binary_read_config': /opt/mesa/src/gallium/drivers/r600/evergreen_compute.c:189: undefined reference to `ac_shader_binary_config_start' ../../../../src/gallium/drivers/r600/.libs/libr600.a(evergreen_compute.o): In function `evergreen_create_compute_state': /opt/mesa/src/gallium/drivers/r600/evergreen_compute.c:254: undefined reference to `ac_elf_read' collect2: error: ld returned 1 exit status Even after 'make distclean'. Cheers, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600: link against common ac library.
This one fixes --enable-opencl (apart from Timothy's 'fix' commit), but NOT nine... Making all in targets/d3dadapter9 make[4]: Entering directory '/opt/mesa/src/gallium/targets/d3dadapter9' CXXLDd3dadapter9.la ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o): In function `ac_elf_read': /opt/mesa/src/amd/common/ac_binary.c:114: multiple definition of `ac_elf_read' ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o):/opt/mesa/src/amd/common/ac_binary.c:114: first defined here ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o): In function `ac_shader_binary_config_start': /opt/mesa/src/amd/common/ac_binary.c:196: multiple definition of `ac_shader_binary_config_start' ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o):/opt/mesa/src/amd/common/ac_binary.c:196: first defined here ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o): In function `ac_shader_binary_read_config': /opt/mesa/src/amd/common/ac_binary.c:216: multiple definition of `ac_shader_binary_read_config' ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o):/opt/mesa/src/amd/common/ac_binary.c:216: first defined here ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_llvm_build.o): In function `ac_llvm_context_init': [-] And so on... I'm using: ./autogen.sh --prefix=/usr/local --with-dri-drivers="" --with-gallium-drivers=r600,radeonsi,swrast --with-egl-platforms=drm --enable-nine --enable-texture-float --enable-opencl --with-vulkan-drivers=radeon Thanks, Dieter Am 28.02.2017 06:05, schrieb Dave Airlie: From: Dave Airlie This should fix the build. Signed-off-by: Dave Airlie --- src/gallium/drivers/r600/Automake.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/r600/Automake.inc b/src/gallium/drivers/r600/Automake.inc index 914eea3..0355455 100644 --- a/src/gallium/drivers/r600/Automake.inc +++ b/src/gallium/drivers/r600/Automake.inc @@ -4,6 +4,7 @@ TARGET_DRIVERS += r600 TARGET_CPPFLAGS += -DGALLIUM_R600 TARGET_LIB_DEPS += \ $(top_builddir)/src/gallium/drivers/r600/libr600.la \ + $(top_builddir)/src/amd/common/libamd_common.la \ $(RADEON_LIBS) \ $(LIBDRM_LIBS) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600: link against common ac library.
Ugh, Timothy's commit (4d0d813) was NOT enough, then with THIS I get the below and after reverting THIS I'm set... [-] make[1]: Entering directory '/opt/mesa' make[1]: Nothing to be done for 'all-am'. make[1]: Leaving directory '/opt/mesa' -Dieter Am 28.02.2017 06:19, schrieb Dieter Nützel: This one fixes --enable-opencl (apart from Timothy's 'fix' commit), but NOT nine... Making all in targets/d3dadapter9 make[4]: Entering directory '/opt/mesa/src/gallium/targets/d3dadapter9' CXXLDd3dadapter9.la ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o): In function `ac_elf_read': /opt/mesa/src/amd/common/ac_binary.c:114: multiple definition of `ac_elf_read' ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o):/opt/mesa/src/amd/common/ac_binary.c:114: first defined here ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o): In function `ac_shader_binary_config_start': /opt/mesa/src/amd/common/ac_binary.c:196: multiple definition of `ac_shader_binary_config_start' ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o):/opt/mesa/src/amd/common/ac_binary.c:196: first defined here ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o): In function `ac_shader_binary_read_config': /opt/mesa/src/amd/common/ac_binary.c:216: multiple definition of `ac_shader_binary_read_config' ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_binary.o):/opt/mesa/src/amd/common/ac_binary.c:216: first defined here ../../../../src/amd/common/.libs/libamd_common.a(common_libamd_common_la-ac_llvm_build.o): In function `ac_llvm_context_init': [-] And so on... I'm using: ./autogen.sh --prefix=/usr/local --with-dri-drivers="" --with-gallium-drivers=r600,radeonsi,swrast --with-egl-platforms=drm --enable-nine --enable-texture-float --enable-opencl --with-vulkan-drivers=radeon Thanks, Dieter Am 28.02.2017 06:05, schrieb Dave Airlie: From: Dave Airlie This should fix the build. Signed-off-by: Dave Airlie --- src/gallium/drivers/r600/Automake.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/r600/Automake.inc b/src/gallium/drivers/r600/Automake.inc index 914eea3..0355455 100644 --- a/src/gallium/drivers/r600/Automake.inc +++ b/src/gallium/drivers/r600/Automake.inc @@ -4,6 +4,7 @@ TARGET_DRIVERS += r600 TARGET_CPPFLAGS += -DGALLIUM_R600 TARGET_LIB_DEPS += \ $(top_builddir)/src/gallium/drivers/r600/libr600.la \ + $(top_builddir)/src/amd/common/libamd_common.la \ $(RADEON_LIBS) \ $(LIBDRM_LIBS) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] List of unsupported extensions per driver
Am 29.07.2015 06:35, schrieb Romain Failliot: Hi! First, I wanted to thank you for the incredible work you've done to achieve OpenGL 4.1. The number of visitors exploded on mesamatrix, while the average was around 100 visits per day, I had more than 2500 visits just for the day of the news! This simple fact shows how much this news was expected by the community ;) You are 'Heise'd' (from Germany)... http://www.heise.de/open/meldung/Quelloffene-Linux-3D-Treiber-bekommen-OpenGL-4-0-Unterstuetzung-2760942.html ;-) Good work, everybody!!! Cheers, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] r600g: fix the single-sample fast clear setup
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák
No effect, but this is what we should be doing.
Hello Marek,
who should test this on which stuff?
BTW Do you think, we see GL 4.1 on r600g (Turks ;-) with 11.0.1?
Great work!
-Dieter
---
src/gallium/drivers/r600/evergreen_state.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 7065af9..5c8fd0d 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1028,7 +1028,10 @@ void evergreen_init_color_surface(struct
r600_context *rctx,
macro_aspect = rtex->surface.mtilea;
bankw = rtex->surface.bankw;
bankh = rtex->surface.bankh;
- fmask_bankh = rtex->fmask.bank_height;
+ if (rtex->fmask.size)
+ fmask_bankh = rtex->fmask.bank_height;
+ else
+ fmask_bankh = rtex->surface.bankh;
tile_split = eg_tile_split(tile_split);
macro_aspect = eg_macro_tile_aspect(macro_aspect);
bankw = eg_bank_wh(bankw);
@@ -1149,10 +1152,11 @@ void evergreen_init_color_surface(struct
r600_context *rctx,
surf->cb_color_attrib = color_attrib;
if (rtex->fmask.size) {
surf->cb_color_fmask = (base_offset + rtex->fmask.offset) >> 8;
+ surf->cb_color_fmask_slice =
S_028C88_TILE_MAX(rtex->fmask.slice_tile_max);
} else {
surf->cb_color_fmask = surf->cb_color_base;
+ surf->cb_color_fmask_slice = S_028C88_TILE_MAX(slice);
}
- surf->cb_color_fmask_slice =
S_028C88_TILE_MAX(rtex->fmask.slice_tile_max);
surf->color_initialized = true;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák
Fixed by the CB_SHADER_MASK fix.
Hurray,
r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_
fixed.
Mostly 'cause it is NOT on par as before (the 'broken') version.
E.g. 'buddha' was stable at 600 FPS (see below).
Thanks,
Dieter
Without fast clear: with new fixed version:
./objview bobcat.obj &
1130.967407 FPS1299.925171 FPS
1171.957153 FPS1328.50 FPS
1170.75 FPS1328.50 FPS
./objview buddha.obj &
533.25 FPS 560.609985 FPS
543.364258 FPS 574.463013 FPS
542.864380 FPS 574.00 FPS
./objview bunny.obj &
743.25 FPS 811.25 FPS
768.00 FPS 825.50 FPS
765.50 FPS 826.75 FPS
./objview GreatLakesBiplaneHP.obj &
604.848938 FPS 644.00 FPS
617.691406 FPS 658.50 FPS
618.25 FPS 658.50 FPS
Taken from former posts with Michel (about enabling DRI3/glamor):
Mesa-demo's 'objview' show this:
bobcat.obj:~790 => ~1048 fps | ~25% with glamor ~1388 fps
buddha.obj:~370 => ~527 fps | >33% with glamor ~600 fps
bunny.obj:~530 => ~720 fps | >25% with glamor ~863 fps
GreatLakesBiplaneHP.obj:~435 => ~593 fps | >33% with glamor ~687
fps
---
src/gallium/drivers/r600/r600_blit.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 1c59230..8664e03 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -393,12 +393,7 @@ static void r600_clear(struct pipe_context *ctx,
unsigned buffers,
struct r600_context *rctx = (struct r600_context *)ctx;
struct pipe_framebuffer_state *fb = &rctx->framebuffer.state;
- /* Single-sample fast color clear is broken on r600g:
-* https://bugs.freedesktop.org/show_bug.cgi?id=73528
-* https://bugs.freedesktop.org/show_bug.cgi?id=82186
-*/
- if (buffers & PIPE_CLEAR_COLOR && rctx->b.chip_class >= EVERGREEN &&
- rctx->framebuffer.nr_samples > 1) {
+ if (buffers & PIPE_CLEAR_COLOR && rctx->b.chip_class >= EVERGREEN) {
evergreen_do_fast_color_clear(&rctx->b, fb,
&rctx->framebuffer.atom,
&buffers, color);
if (!buffers)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear
Am 02.08.2015 19:54, schrieb Dieter Nützel:
Am 02.08.2015 15:36, schrieb Marek Olšák:
From: Marek Olšák
Fixed by the CB_SHADER_MASK fix.
Hurray,
r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_
fixed.
Mostly 'cause it is NOT on par as before (the 'broken') version.
E.g. 'buddha' was stable at 600 FPS (see below).
Thanks,
Dieter
Tested-by: Dieter Nützel
OK,
I retested with
git revert 97ec2c6 (r600g: disable single-sample fast color clear due to
hangs)
Speed is back (I put all three results together in the below table)
BTW I hadn't any hangs on Evergreen (Turks) with old version.
Any specific test I should try?
-Dieter
Without fast clear: with new fixed version:
git revert 97ec2c6
./objview bobcat.obj &
1130.967407 FPS1299.925171 FPS
1393.75 FPS
1171.957153 FPS1328.50 FPS
1391.75 FPS
1170.75 FPS1328.50 FPS
1392.25 FPS
./objview buddha.obj &
533.25 FPS 560.609985 FPS
602.599487 FPS
543.364258 FPS 574.463013 FPS
601.849670 FPS
542.864380 FPS 574.00 FPS
601.50 FPS
./objview bunny.obj &
743.25 FPS 811.25 FPS
867.283325 FPS
768.00 FPS 825.50 FPS
865.00 FPS
765.50 FPS 826.75 FPS
865.00 FPS
./objview GreatLakesBiplaneHP.obj &
604.848938 FPS 644.00 FPS
688.75 FPS
617.691406 FPS 658.50 FPS
689.50 FPS
618.25 FPS 658.50 FPS
690.00 FPS
Taken from former posts with Michel (about enabling DRI3/glamor):
Mesa-demo's 'objview' show this:
bobcat.obj:~790 => ~1048 fps | ~25% with glamor ~1388 fps
buddha.obj:~370 => ~527 fps | >33% with glamor ~600 fps
bunny.obj:~530 => ~720 fps | >25% with glamor ~863 fps
GreatLakesBiplaneHP.obj:~435 => ~593 fps | >33% with glamor ~687
fps
---
src/gallium/drivers/r600/r600_blit.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 1c59230..8664e03 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -393,12 +393,7 @@ static void r600_clear(struct pipe_context *ctx,
unsigned buffers,
struct r600_context *rctx = (struct r600_context *)ctx;
struct pipe_framebuffer_state *fb = &rctx->framebuffer.state;
- /* Single-sample fast color clear is broken on r600g:
-* https://bugs.freedesktop.org/show_bug.cgi?id=73528
-* https://bugs.freedesktop.org/show_bug.cgi?id=82186
-*/
- if (buffers & PIPE_CLEAR_COLOR && rctx->b.chip_class >= EVERGREEN &&
- rctx->framebuffer.nr_samples > 1) {
+ if (buffers & PIPE_CLEAR_COLOR && rctx->b.chip_class >= EVERGREEN) {
evergreen_do_fast_color_clear(&rctx->b, fb,
&rctx->framebuffer.atom,
&buffers, color);
if (!buffers)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] r600g: re-enable single-sample fast clear
Am 02.08.2015 21:11, schrieb Marek Olšák: On Sun, Aug 2, 2015 at 9:03 PM, Dieter Nützel wrote: Am 02.08.2015 19:54, schrieb Dieter Nützel: Am 02.08.2015 15:36, schrieb Marek Olšák: From: Marek Olšák Fixed by the CB_SHADER_MASK fix. Hurray, r600g (Turks) ~10% performance drop for Mesa's 'objview' is _mostly_ fixed. Mostly 'cause it is NOT on par as before (the 'broken') version. E.g. 'buddha' was stable at 600 FPS (see below). Thanks, Dieter Tested-by: Dieter Nützel OK, I retested with git revert 97ec2c6 (r600g: disable single-sample fast color clear due to hangs) Speed is back (I put all three results together in the below table) BTW I hadn't any hangs on Evergreen (Turks) with old version. Any specific test I should try? This test case hangs on my Redwood without the patches and fast clear enabled: https://bugs.freedesktop.org/attachment.cgi?id=117466 Marek OK, all acked, now. Your test case hangs on Evergreen (Turks) here, too. [14644.548816] radeon :01:00.0: ring 0 stalled for more than 10248msec [14644.548824] radeon :01:00.0: GPU lockup (current fence id 0x0026e33d last fence id 0x0026e33f on ring 0) [14644.569069] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35). [14644.569086] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-35). But I could get logs and reboot... With these patches and fast clear enabled _everything_ is GOOD. Even SPEED! --- Only thing I had to do was a REBOOT. Maybe one of the registers hold the OLD falue? Commit, please. Acked-by: Dieter Nützel Dieter PS We all repeat loud: A reboot now and then could make gfk development go... bobcat.obj 1392.50 FPS 1393.75 FPS 1394.00 FPS buddha.obj 603.698425 FPS 600.25 FPS 600.100098 FPS bunny.obj 867.00 FPS 863.534241 FPS 864.284058 FPS GreatLakesBiplaneHP.obj 691.25 FPS 688.827942 FPS 689.577759 FPS ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] r600g/sb: Handle undef in read port tracker
Hello Glenn,
with your series I got some steps forward on this one:
[r600g] regression: SB-related NI/Turks crash on 'gsraytrace'
https://bugs.freedesktop.org/show_bug.cgi?id=91503
Crash is GONE.
GPU hang is BACK _without_ R600_DEBUG=nosb.
With R600_DEBUG=nosb
vsraytrace, fsraytrace and gsraytrace
show corruption (images are available)
Where should I add them?
Due to Marek's GREAT GALLIUM_DDEBUG stuff I got forward on the GPU hang,
too!
Where should I add these logs?
Dieter
Am 27.08.2015 19:04, schrieb Glenn Kennard:
e8e443 missed adding check for undef values also in
unreserve function, leading to an assert triggering.
Signed-off-by: Glenn Kennard
---
src/gallium/drivers/r600/sb/sb_sched.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_sched.cpp
b/src/gallium/drivers/r600/sb/sb_sched.cpp
index 6268078..c98b8ff 100644
--- a/src/gallium/drivers/r600/sb/sb_sched.cpp
+++ b/src/gallium/drivers/r600/sb/sb_sched.cpp
@@ -236,7 +236,7 @@ void rp_gpr_tracker::unreserve(alu_node* n) {
for (i = 0; i < nsrc; ++i) {
value *v = n->src[i];
- if (v->is_readonly())
+ if (v->is_readonly() || v->is_undef())
continue;
if (i == 1 && opt)
continue;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Was: Re: [PATCH] r600g: Add support for PK2H/UP2H
Ping. - Again.
Ilia and Marek voted for it.
Any progress?
Anyone, Marek, Nicolai?
Should I rebase?
Dieter
[Mesa-dev] [PATCH] r600g: Add support for PK2H/UP2H
Glenn Kennard glenn.kennard at gmail.com
Sun Jan 3 14:47:18 PST 2016
Previous message: [Mesa-dev] [PATCH 1/2] WIP gallivm: add support for
PK2H/UP2H Next message: [Mesa-dev] [PATCH] mesa: use gl_shader_variable
in
program resource list Messages sorted by: [ date ] [ thread ] [ subject
] [
author ]
Based off of Ilia's original patch, but with output values replicated
so
that it matches the TGSI semantics.
Signed-off-by: Glenn Kennard
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 107
+++-- 2 files changed, 104 insertions(+),
5
deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c index d71082f..3b5d26c 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -328,6 +328,7 @@ static int r600_get_param(struct pipe_screen*
pscreen,
enum pipe_cap param)>
case PIPE_CAP_TEXTURE_QUERY_LOD:
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
case PIPE_CAP_SAMPLER_VIEW_TARGET:
+ case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
return family >= CHIP_CEDAR ? 1 : 0;
case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
return family >= CHIP_CEDAR ? 4 : 0;
@@ -349,7 +350,6 @@ static int r600_get_param(struct pipe_screen*
pscreen,
enum pipe_cap param)>
case PIPE_CAP_SHAREABLE_SHADERS:
case PIPE_CAP_CLEAR_TEXTURE:
case PIPE_CAP_DRAW_PARAMETERS:
- case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
return 0;
case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c index 9c040ae..7b1eade 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -8960,6 +8960,105 @@ static int tgsi_umad(struct r600_shader_ctx
*ctx)
return 0;
}
+static int tgsi_pk2h(struct r600_shader_ctx *ctx)
+{
+ struct tgsi_full_instruction *inst =
&ctx->parse.FullToken.FullInstruction;
+ struct r600_bytecode_alu alu;
+ int r, i;
+ int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
+
+ /* temp.xy = f32_to_f16(src) */
+ memset(&alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP1_FLT32_TO_FLT16;
+ alu.dst.chan = 0;
+ alu.dst.sel = ctx->temp_reg;
+ alu.dst.write = 1;
+ r600_bytecode_src(&alu.src[0], &ctx->src[0], 0);
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+ alu.dst.chan = 1;
+ r600_bytecode_src(&alu.src[0], &ctx->src[0], 1);
+ alu.last = 1;
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+
+ /* dst.x = temp.y * 0x1 + temp.x */
+ for (i = 0; i < lasti + 1; i++) {
+ if (!(inst->Dst[0].Register.WriteMask & (1 << i)))
+ continue;
+
+ memset(&alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP3_MULADD_UINT24;
+ alu.is_op3 = 1;
+ tgsi_dst(ctx, &inst->Dst[0], i, &alu.dst);
+ alu.last = i == lasti;
+ alu.src[0].sel = ctx->temp_reg;
+ alu.src[0].chan = 1;
+ alu.src[1].sel = V_SQ_ALU_SRC_LITERAL;
+ alu.src[1].value = 0x1;
+ alu.src[2].sel = ctx->temp_reg;
+ alu.src[2].chan = 0;
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+ }
+
+ return 0;
+}
+
+static int tgsi_up2h(struct r600_shader_ctx *ctx)
+{
+ struct tgsi_full_instruction *inst =
&ctx->parse.FullToken.FullInstruction;
+ struct r600_bytecode_alu alu;
+ int r, i;
+ int lasti = tgsi_last_instruction(inst->Dst[0].Register.WriteMask);
+
+ /* temp.x = src.x */
+ /* note: no need to mask out the high bits */
+ memset(&alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP1_MOV;
+ alu.dst.chan = 0;
+ alu.dst.sel = ctx->temp_reg;
+ alu.dst.write = 1;
+ r600_bytecode_src(&alu.src[0], &ctx->src[0], 0);
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+
+ /* temp.y = src.x >> 16 */
+ memset(&alu, 0, sizeof(struct r600_bytecode_alu));
+ alu.op = ALU_OP2_LSHR_INT;
+ alu.dst.chan = 1;
+ alu.dst.sel = ctx->temp_reg;
+ alu.dst.write = 1;
+ r600_bytecode_src(&alu.src[0], &ctx->src[0], 0);
+ alu.src[1].sel = V_SQ_ALU_SRC_LITERAL;
+ alu.src[1].value = 16;
+ alu.last = 1;
+ r = r600_bytecode_add_alu(ctx->bc, &alu);
+ if (r)
+ return r;
+
+ /* dst.wz = dst.xy = f16_to_f32(temp.xy) */
+
Re: [Mesa-dev] [PATCH 1/4] radeon/vce: allocate at least 4KB of memory for the feedback buffer
[bisected]
gallium/radeon: add query fences and r600_get_hw_query_params
introduce regression on r600g/NI/Turks XT with Blender 2.76.
Picking/selecting with right mouse button result in SIG:
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
radeon: The kernel rejected CS, see dmesg for more information (-22).
Writing: /tmp/bh.crash.txt
[1]Segmentation faultblender
_This_ patch do _NOT_ solve it.
631c47384c1f45450359fd7d1df2c5f0c79f40bc is the first bad commit
commit 631c47384c1f45450359fd7d1df2c5f0c79f40bc
Author: Nicolai Hähnle
Date: Wed Sep 14 10:38:33 2016 +0200
gallium/radeon: add query fences and r600_get_hw_query_params
We will support the waiting option in ARB_query_buffer_object using
WAIT_REG_MEM on an appropriate fence-like dword. Some queries
conveniently
write their results with the highest bit set, and we can just use
that;
for others, we have to write a fence explicitly.
ZPASS_DONE for occlusion queries writes its results with the high
bit
set, but it writes up to 8 pairs of results (one for each DB). We
have
to wait for all of these results, so let's just add an explicit
fence.
The new function provides summary information to be used by
subsequent
patches.
Reviewed-by: Edward O'Callaghan
Reviewed-by: Marek Olšák
:04 04 bed7362ecccdebb63b505d50b3777dc10963aef9
fe9ca1f733c7897e1362194240e114482f91bbb3 M src
Regards,
Dieter.
Am 29.09.2016 18:35, schrieb Nicolai Hähnle:
From: Nicolai Hähnle
The kernel's CS checker requires it. This fixes a regression introduced
by
the buffer sub-allocation.
Cc: Christian König
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97976
---
src/gallium/drivers/radeon/radeon_vce.c | 6 +++---
src/gallium/drivers/radeon/radeon_video.c | 12
src/gallium/drivers/radeon/radeon_video.h | 3 +++
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_vce.c
b/src/gallium/drivers/radeon/radeon_vce.c
index 10c5a78..dd4c367 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -232,21 +232,21 @@ void rvce_frame_offset(struct rvce_encoder *enc,
struct rvce_cpb_slot *slot,
}
/**
* destroy this video encoder
*/
static void rvce_destroy(struct pipe_video_codec *encoder)
{
struct rvce_encoder *enc = (struct rvce_encoder*)encoder;
if (enc->stream_handle) {
struct rvid_buffer fb;
- rvid_create_buffer(enc->screen, &fb, 512, PIPE_USAGE_STAGING);
+ rvid_create_feedback_buffer(enc->screen, &fb);
enc->fb = &fb;
enc->session(enc);
enc->feedback(enc);
enc->destroy(enc);
flush(enc);
rvid_destroy_buffer(&fb);
}
rvid_destroy_buffer(&enc->cpb);
enc->ws->cs_destroy(enc->cs);
FREE(enc->cpb_array);
@@ -275,21 +275,21 @@ static void rvce_begin_frame(struct
pipe_video_codec *encoder,
if (pic->picture_type == PIPE_H264_ENC_PICTURE_TYPE_IDR)
reset_cpb(enc);
else if (pic->picture_type == PIPE_H264_ENC_PICTURE_TYPE_P ||
pic->picture_type == PIPE_H264_ENC_PICTURE_TYPE_B)
sort_cpb(enc);
if (!enc->stream_handle) {
struct rvid_buffer fb;
enc->stream_handle = rvid_alloc_stream_handle();
- rvid_create_buffer(enc->screen, &fb, 512, PIPE_USAGE_STAGING);
+ rvid_create_feedback_buffer(enc->screen, &fb);
enc->fb = &fb;
enc->session(enc);
enc->create(enc);
enc->config(enc);
enc->feedback(enc);
flush(enc);
//dump_feedback(enc, &fb);
rvid_destroy_buffer(&fb);
need_rate_control = false;
}
@@ -304,21 +304,21 @@ static void rvce_begin_frame(struct
pipe_video_codec *encoder,
static void rvce_encode_bitstream(struct pipe_video_codec *encoder,
struct pipe_video_buffer *source,
struct pipe_resource *destination,
void **fb)
{
struct rvce_encoder *enc = (struct rvce_encoder*)encoder;
enc->get_buffer(destination, &enc->bs_handle, NULL);
enc->bs_size = destination->width0;
*fb = enc->fb = CALLOC_STRUC
Re: [Mesa-dev] [PATCH 1/4] radeon/vce: allocate at least 4KB of memory for the feedback buffer
Am 29.09.2016 22:34, schrieb Dieter Nützel: [bisected] gallium/radeon: add query fences and r600_get_hw_query_params introduce regression on r600g/NI/Turks XT with Blender 2.76. Picking/selecting with right mouse button result in SIG: radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). radeon: The kernel rejected CS, see dmesg for more information (-22). Writing: /tmp/bh.crash.txt [1]Segmentation faultblender _This_ patch do _NOT_ solve it. 631c47384c1f45450359fd7d1df2c5f0c79f40bc is the first bad commit commit 631c47384c1f45450359fd7d1df2c5f0c79f40bc Author: Nicolai Hähnle Date: Wed Sep 14 10:38:33 2016 +0200 gallium/radeon: add query fences and r600_get_hw_query_params We will support the waiting option in ARB_query_buffer_object using WAIT_REG_MEM on an appropriate fence-like dword. Some queries conveniently write their results with the highest bit set, and we can just use that; for others, we have to write a fence explicitly. ZPASS_DONE for occlusion queries writes its results with the high bit set, but it writes up to 8 pairs of results (one for each DB). We have to wait for all of these results, so let's just add an explicit fence. The new function provides summary information to be used by subsequent patches. Reviewed-by: Edward O'Callaghan Reviewed-by: Marek Olšák :04 04 bed7362ecccdebb63b505d50b3777dc10963aef9 fe9ca1f733c7897e1362194240e114482f91bbb3 M src Regards, Dieter. Addendum (read the logs carefully...): [25614.322361] [drm:radeon_cs_packet_next_reloc [radeon]] *ERROR* No packet3 for relocation for packet at 303. [25614.322363] [drm] ib[303]=0xC0044700 [25614.322364] [drm] ib[304]=0x0528 [25614.322364] [drm] ib[305]=0x0080 [25614.322364] [drm] ib[306]=0x2000 [25614.322365] [drm] ib[307]=0x8000 [25614.322365] [drm] ib[308]=0x [25614.322384] [drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* bad EVENT_WRITE [25614.322399] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! [25614.322631] [drm:radeon_cs_packet_next_reloc [radeon]] *ERROR* No packet3 for relocation for packet at 717. [25614.322636] [drm] ib[717]=0xC0044700 [25614.322636] [drm] ib[718]=0x0528 [25614.322637] [drm] ib[719]=0x0080 [25614.322637] [drm] ib[720]=0x2000 [25614.322638] [drm] ib[721]=0x8000 [25614.322638] [drm] ib[722]=0x [25614.322656] [drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* bad EVENT_WRITE [25614.322669] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! [25614.323004] [drm:radeon_cs_packet_next_reloc [radeon]] *ERROR* No packet3 for relocation for packet at 706. [25614.323005] [drm] ib[706]=0xC0044700 [25614.323006] [drm] ib[707]=0x0528 [25614.323006] [drm] ib[708]=0x0080 [25614.323007] [drm] ib[709]=0x2000 [25614.323007] [drm] ib[710]=0x8000 [25614.323007] [drm] ib[711]=0x [25614.323025] [drm:evergreen_packet3_check.isra.14 [radeon]] *ERROR* bad EVENT_WRITE [25614.323039] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! Cheers, Dieter. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/5] gallium/radeon: emit relocations for query fences
Fixed all Blender issues on r600g/NI/Turks XT.
Apart from that that it's already committed you have my
Tb
Thank you Nicolai!
Dieter.
Am 30.09.2016 11:52, schrieb Nicolai Hähnle:
From: Nicolai Hähnle
This is only needed for r600 which doesn't have ARB_query_buffer_object
and
therefore wouldn't really need the fences, but let's be optimistic
about
filling in this feature gap eventually.
Cc: Dieter Nützel
---
src/gallium/drivers/radeon/r600_pipe_common.c | 7 ++-
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeon/r600_query.c | 13 +++--
src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
4 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index e9377b2..6dc92cb 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -73,21 +73,21 @@ void radeon_shader_binary_clean(struct
radeon_shader_binary *b)
FREE(b->global_symbol_offsets);
FREE(b->relocs);
FREE(b->disasm_string);
FREE(b->llvm_ir_string);
}
/*
* pipe_context
*/
-void r600_gfx_write_fence(struct r600_common_context *ctx,
+void r600_gfx_write_fence(struct r600_common_context *ctx, struct
r600_resource *buf,
uint64_t va, uint32_t old_value, uint32_t new_value)
{
struct radeon_winsys_cs *cs = ctx->gfx.cs;
if (ctx->chip_class == CIK) {
/* Two EOP events are required to make all engines go idle
* (and optional cache flushes executed) before the timestamp
* is written.
*/
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
@@ -99,29 +99,34 @@ void r600_gfx_write_fence(struct
r600_common_context *ctx,
radeon_emit(cs, 0); /* unused */
}
radeon_emit(cs, PKT3(PKT3_EVENT_WRITE_EOP, 4, 0));
radeon_emit(cs, EVENT_TYPE(EVENT_TYPE_BOTTOM_OF_PIPE_TS) |
EVENT_INDEX(5));
radeon_emit(cs, va);
radeon_emit(cs, (va >> 32) | EOP_DATA_SEL(1));
radeon_emit(cs, new_value); /* immediate data */
radeon_emit(cs, 0); /* unused */
+
+ r600_emit_reloc(ctx, &ctx->gfx, buf, RADEON_USAGE_WRITE,
RADEON_PRIO_QUERY);
}
unsigned r600_gfx_write_fence_dwords(struct r600_common_screen
*screen)
{
unsigned dwords = 6;
if (screen->chip_class == CIK)
dwords *= 2;
+ if (!screen->info.has_virtual_memory)
+ dwords += 2;
+
return dwords;
}
void r600_gfx_wait_fence(struct r600_common_context *ctx,
uint64_t va, uint32_t ref, uint32_t mask)
{
struct radeon_winsys_cs *cs = ctx->gfx.cs;
radeon_emit(cs, PKT3(PKT3_WAIT_REG_MEM, 5, 0));
radeon_emit(cs, WAIT_REG_MEM_EQUAL | WAIT_REG_MEM_MEM_SPACE(1));
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index ec7f7c0..cdcc80b 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -696,21 +696,21 @@ struct pipe_resource *
r600_aligned_buffer_create(struct pipe_screen *screen,
unsigned alignment);
struct pipe_resource *
r600_buffer_from_user_memory(struct pipe_screen *screen,
const struct pipe_resource *templ,
void *user_memory);
void
r600_invalidate_resource(struct pipe_context *ctx,
struct pipe_resource *resource);
/* r600_common_pipe.c */
-void r600_gfx_write_fence(struct r600_common_context *ctx,
+void r600_gfx_write_fence(struct r600_common_context *ctx, struct
r600_resource *buf,
uint64_t va, uint32_t old_value, uint32_t new_value);
unsigned r600_gfx_write_fence_dwords(struct r600_common_screen
*screen);
void r600_gfx_wait_fence(struct r600_common_context *ctx,
uint64_t va, uint32_t ref, uint32_t mask);
void r600_draw_rectangle(struct blitter_context *blitter,
int x1, int y1, int x2, int y2, float depth,
enum blitter_attrib_type type,
const union pipe_color_union *attrib);
bool r600_common_screen_init(struct r600_common_screen *rscreen,
struct radeon_winsys *ws);
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 0908a6c..925c950 100644
--- a/src/gallium/drivers/radeon/r600_query.c
+++ b/src/gallium/drivers/radeon/r600_query.c
@@ -609,32 +609,32 @@ static void r600_query_hw_emit_start(struct
r600_common_context *ctx,
ctx->num_cs_dw_queries_suspend += query->num_cs_dw_end;
}
stati
[Mesa-dev] [RADV] vk_format.h:147:1: unknown type name 'uint' - is my compiler overage?
gcc (SUSE Linux) 4.8.3 make[4]: Entering directory '/opt/mesa/src/amd/vulkan' Updating radv_timestamp.h GEN radv_timestamp.h CC radv_device.lo CC vk_format_table.lo In file included from vk_format_table.c:31:0: vk_format.h:147:1: error: unknown type name 'uint' vk_format_get_blocksizebits(VkFormat format) ^ vk_format.h:163:1: error: unknown type name 'uint' vk_format_get_blocksize(VkFormat format) ^ vk_format.h: In function 'vk_format_get_blocksize': vk_format.h:165:2: error: unknown type name 'uint' uint bits = vk_format_get_blocksizebits(format); ^ vk_format.h:166:2: error: unknown type name 'uint' uint bytes = bits / 8; ^ vk_format.h: At top level: vk_format.h:178:1: error: unknown type name 'uint' vk_format_get_blockwidth(VkFormat format) ^ vk_format.h:191:1: error: unknown type name 'uint' vk_format_get_blockheight(VkFormat format) ^ vk_format.h:406:1: error: unknown type name 'uint' vk_format_get_component_bits(VkFormat format, ^ vk_format.h:408:9: error: unknown type name 'uint' uint component) ^ Makefile:917: recipe for target 'vk_format_table.lo' failed make[4]: *** [vk_format_table.lo] Error 1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] loader/dri3: Overhaul dri3_update_num_back
Am 25.08.2016 11:09, schrieb Michel Dänzer: On 24/08/16 06:35 AM, Eric Anholt wrote: Michel Dänzer writes: On 20/08/16 04:42 AM, Eric Anholt wrote: Michel Dänzer writes: From: Michel Dänzer Always use 3 buffers when flipping. With only 2 buffers, we have to wait for a flip to complete (which takes non-0 time even with asynchronous flips) before we can start working on the next frame. We were previously only using 2 buffers for flipping if the X server supports asynchronous flips, even when we're not using asynchronous flips. This could result in bad performance (the referenced bug report is an extreme case, where the inter-frame stalls were preventing the GPU from reaching its maximum clocks). I couldn't measure any performance boost using 4 buffers with flipping. Performance actually seemed to go down slightly, but that might have been just noise. Without flipping, a single back buffer is enough for swap interval 0, but we need to use 2 back buffers when the swap interval is non-0, otherwise we have to wait for the swap interval to pass before we can start working on the next frame. This condition was previously reversed. Cc: "12.0 11.2" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97260 Signed-off-by: Michel Dänzer Reviewed-by: Eric Anholt Thanks. Hello Michel, found this _before_ your commit, but haven't had time, so... With this patch Blender at least 2.76b flicker horribly with 'User Preferences...' -> 'Window Draw Method: Automatic' Switching to: 'Window Draw Method: Tripple Buffer' fix it. I'll add this to the related bug if you want. Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 2/2] docs/helpwanted: fix GL3.txt/features.txt link
Am 30.08.2016 22:16, schrieb Eric Engestrom:
Fixes: f926cf5bd0ade3273b32 ("docs: Rename GL3.txt to features.txt")
CC: Ian Romanick
CC: Andreas Boll
Signed-off-by: Eric Engestrom
---
docs/helpwanted.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/helpwanted.html b/docs/helpwanted.html
index 859e65c..0660a9e 100644
--- a/docs/helpwanted.html
+++ b/docs/helpwanted.html
@@ -56,8 +56,8 @@
Common To-Do lists:
- href="http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt";>
-GL3.txt - Status of OpenGL 3.x / 4.x features in
Mesa.
+ href="http://cgit.freedesktop.org/mesa/mesa/tree/docs/features.txt";>
+features.txt - Status of OpenGL 3.x / 4.x features in
Mesa.
Shouldn't this look like this:
+features.txt - Status of OpenGL 3.x / 4.x / other
extensions features in Mesa.
Or the like?
Only a thought.
http://dri.freedesktop.org/wiki/MissingFunctionality";>
MissingFunctionality - Detailed information about
missing OpenGL features.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc3 / CC'ing Mesa-devel
Hello Emil, if this commit commit 81a95946dab730c1cfcf04ac1373cea5f7908f65 Author: Marek Olšák Date: Thu Oct 20 22:57:03 2016 +0200 gallium/radeon: fold radeon_winsys::surface_best into radeon/winsys Reviewed-by: Nicolai Hähnle hits 13.0.0 then I've found an regression on r600g NI/Turks XT. It show up as texture corruption with FreeCAD (MSAA 8x context) and under LS2015 (wine-1.9.21~gallium_nine+staging / MSAA 2+). I'll open a ticket in some minutes. How can I switch Mesa master to 13.0.0-rc3, too test? I'll tried but couldn't found any 13.0.0-rc3 tag. Thanks, Dieter Am 31.10.2016 13:21, schrieb Emil Velikov: The third release candidate for Mesa 13.0.0 is now available with the final to be out in ~24 hours. Maintainers, this is a polite reminder to test your respective drivers and/or subsystem. If there are any severe issues with unmerged patches let me know and we'll include them. Axel Davy (3): st/nine: Fix leak with integer and boolean constants st/nine: Fix mistake in Volume9 UnlockBox st/nine: Fix locking CubeTexture surfaces. Dave Airlie (1): radv/ac/llvm: trim texture return values Emil Velikov (2): cherry-ignore: add mapi VISILITY_CFLAGS patch Update version to 13.0.0-rc3 Eric Engestrom (1): egl/dri2: swap_buffers_with_damage falls back to swap_buffers Fredrik Höglund (3): radv: mark the fence as submitted and signalled in vkAcquireNextImageKHR vulkan/wsi/x11: fix ARGB window support vulkan/wsi/wayland: fix ARGB window support Kenneth Graunke (6): i965: Drop unnecessary switch statement in nir_setup_outputs() i965: Make split_virtual_grfs() call compact_virtual_grfs(). i965: Don't use nir_assign_var_locations for VS/TES/GS outputs. i965: Drop nir_inputs from fs_visitor. glsl: Pass ctx to program interface query helper functions. glsl: Size TCS->TES unsized arrays to gl_MaxPatchVertices for queries. Marek Olšák (5): gallium/radeon: fix incorrect bpe use in si_set_optimal_micro_tile_mode gallium/radeon: make sure the address of separate CMASK is aligned properly winsys/amdgpu: fix radeon_surf::macro_tile_index for imported textures st/mesa: unduplicate st_check_sync code st/mesa: allow multiple concurrent waiters in ClientWaitSync Matt Turner (2): anv: Replace "abi_versions" with correct "api_version". radv: Replace "abi_versions" with correct "api_version". Nicolai Hähnle (1): st/mesa: cleanup and fix primitive restart for indirect draws Samuel Iglesias Gonsálvez (2): mesa/program: Add _mesa_symbol_table_replace_symbol() glsl: update default precision qualifier when it is set in the shader Samuel Pitoiset (2): nvc0: use correct bufctx when invalidating CP textures nvc0/ir: fix emission of SHLADD with NEG modifiers Tapani Pälli (5): egl/dri2: set max values for pbuffer width and height Revert "egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT" egl: add check that eglCreateContext gets a valid config mesa: fix error handling in DrawBuffers egl: set preserved behavior for surface only if config supports it Timothy Arceri (1): glsl/mesa: remove unused namespace support from the symbol table git tag: mesa-13.0.0-rc3 https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz MD5: 49923a2add7a026de669b66d4241d6e5 mesa-13.0.0-rc3.tar.gz SHA1: 358eed62654a472365153687577d0ef04cc8deec mesa-13.0.0-rc3.tar.gz SHA256: 99924e8c3c62050b45d160486c94f0efb75ad3ae10890230e1dd154bde86a4b9 mesa-13.0.0-rc3.tar.gz PGP: https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz.sig https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.xz MD5: 599f1b7879ee2ca1bd8235f51771b5d0 mesa-13.0.0-rc3.tar.xz SHA1: bfd7628b36f361e7c6a080169c7be8961da62b6d mesa-13.0.0-rc3.tar.xz SHA256: 4a3ec9e93cc2be964e204a591a88d8aa935d988fcba877a56e66441f1ebe681a mesa-13.0.0-rc3.tar.xz PGP: https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.xz.sig ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc3
Am 31.10.2016 19:33, schrieb Emil Velikov: On 31 October 2016 at 18:16, Dieter Nützel wrote: Hello Emil, if this commit commit 81a95946dab730c1cfcf04ac1373cea5f7908f65 Author: Marek Olšák Date: Thu Oct 20 22:57:03 2016 +0200 gallium/radeon: fold radeon_winsys::surface_best into radeon/winsys Reviewed-by: Nicolai Hähnle hits 13.0.0 then I've found an regression on r600g NI/Turks XT. It show up as texture corruption with FreeCAD (MSAA 8x context) and under LS2015 (wine-1.9.21~gallium_nine+staging / MSAA 2+). I'll open a ticket in some minutes. Great thank you ! Feel free to CC me on it. I did. The above patch hasn't landed in 13.0.0 and from a quick look it's a cleanup/refactoring which doesn't fit the criteria. Barring any notable reasoning of course. OK, go on with 13.0.0. I've tested it some minutes ago. It is only in git master (committed five days ago). How can I switch Mesa master to 13.0.0-rc3, too test? I'll tried but couldn't found any 13.0.0-rc3 tag. Looks like you're missing the "mesa-" part of the tag. Just do Yep. $git fetch --all $git checkout -b foo mesa-13.0.0-rc3 That was it. I did a grep -r 13.0.0-rc3 * before but only got 13.1... Sorry for the noise. Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc3 / CC'ing Mesa-devel
Am 31.10.2016 21:22, schrieb Marek Olšák:
Hi,
Hello Marek!
Can you try to replace:
if (!(surf_ws->flags & RADEON_SURF_IMPORTED)) {
with:
if (!(surf_ws->flags & (RADEON_SURF_IMPORTED | RADEON_SURF_FMASK))) {
?
Marek
I've tried 2 times to be sure. No luck.
Any other idea?
I looked over the code but saw nothing.
Could it be in another file?
Dieter
On Mon, Oct 31, 2016 at 7:21 PM, Dieter Nützel
wrote:
Hello Emil,
if this commit
commit 81a95946dab730c1cfcf04ac1373cea5f7908f65
Author: Marek Olšák
Date: Thu Oct 20 22:57:03 2016 +0200
gallium/radeon: fold radeon_winsys::surface_best into
radeon/winsys
Reviewed-by: Nicolai Hähnle
hits 13.0.0 then I've found an regression on r600g NI/Turks XT.
It show up as texture corruption with FreeCAD (MSAA 8x context) and
under
LS2015 (wine-1.9.21~gallium_nine+staging / MSAA 2+).
I'll open a ticket in some minutes.
How can I switch Mesa master to 13.0.0-rc3, too test?
I'll tried but couldn't found any 13.0.0-rc3 tag.
Thanks,
Dieter
Am 31.10.2016 13:21, schrieb Emil Velikov:
The third release candidate for Mesa 13.0.0 is now available with the
final
to be out in ~24 hours.
Maintainers, this is a polite reminder to test your respective
drivers
and/or
subsystem. If there are any severe issues with unmerged patches let
me
know and
we'll include them.
Axel Davy (3):
st/nine: Fix leak with integer and boolean constants
st/nine: Fix mistake in Volume9 UnlockBox
st/nine: Fix locking CubeTexture surfaces.
Dave Airlie (1):
radv/ac/llvm: trim texture return values
Emil Velikov (2):
cherry-ignore: add mapi VISILITY_CFLAGS patch
Update version to 13.0.0-rc3
Eric Engestrom (1):
egl/dri2: swap_buffers_with_damage falls back to swap_buffers
Fredrik Höglund (3):
radv: mark the fence as submitted and signalled in
vkAcquireNextImageKHR
vulkan/wsi/x11: fix ARGB window support
vulkan/wsi/wayland: fix ARGB window support
Kenneth Graunke (6):
i965: Drop unnecessary switch statement in nir_setup_outputs()
i965: Make split_virtual_grfs() call compact_virtual_grfs().
i965: Don't use nir_assign_var_locations for VS/TES/GS outputs.
i965: Drop nir_inputs from fs_visitor.
glsl: Pass ctx to program interface query helper functions.
glsl: Size TCS->TES unsized arrays to gl_MaxPatchVertices for
queries.
Marek Olšák (5):
gallium/radeon: fix incorrect bpe use in
si_set_optimal_micro_tile_mode
gallium/radeon: make sure the address of separate CMASK is
aligned properly
winsys/amdgpu: fix radeon_surf::macro_tile_index for imported
textures
st/mesa: unduplicate st_check_sync code
st/mesa: allow multiple concurrent waiters in ClientWaitSync
Matt Turner (2):
anv: Replace "abi_versions" with correct "api_version".
radv: Replace "abi_versions" with correct "api_version".
Nicolai Hähnle (1):
st/mesa: cleanup and fix primitive restart for indirect draws
Samuel Iglesias Gonsálvez (2):
mesa/program: Add _mesa_symbol_table_replace_symbol()
glsl: update default precision qualifier when it is set in the
shader
Samuel Pitoiset (2):
nvc0: use correct bufctx when invalidating CP textures
nvc0/ir: fix emission of SHLADD with NEG modifiers
Tapani Pälli (5):
egl/dri2: set max values for pbuffer width and height
Revert "egl/android: Set EGL_MAX_PBUFFER_WIDTH and
EGL_MAX_PBUFFER_HEIGHT"
egl: add check that eglCreateContext gets a valid config
mesa: fix error handling in DrawBuffers
egl: set preserved behavior for surface only if config supports
it
Timothy Arceri (1):
glsl/mesa: remove unused namespace support from the symbol
table
git tag: mesa-13.0.0-rc3
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz
MD5: 49923a2add7a026de669b66d4241d6e5 mesa-13.0.0-rc3.tar.gz
SHA1: 358eed62654a472365153687577d0ef04cc8deec
mesa-13.0.0-rc3.tar.gz
SHA256:
99924e8c3c62050b45d160486c94f0efb75ad3ae10890230e1dd154bde86a4b9
mesa-13.0.0-rc3.tar.gz
PGP:
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz.sig
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.xz
MD5: 599f1b7879ee2ca1bd8235f51771b5d0 mesa-13.0.0-rc3.tar.xz
SHA1: bfd7628b36f361e7c6a080169c7be8961da62b6d
mesa-13.0.0-rc3.tar.xz
SHA256:
4a3ec9e93cc2be964e204a591a88d8aa935d988fcba877a56e66441f1ebe681a
mesa-13.0.0-rc3.tar.xz
PGP:
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.xz.sig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc3 / CC'ing Mesa-devel
Am 31.10.2016 22:41, schrieb Dieter Nützel:
Am 31.10.2016 21:22, schrieb Marek Olšák:
Hi,
Hello Marek!
Can you try to replace:
if (!(surf_ws->flags & RADEON_SURF_IMPORTED)) {
with:
if (!(surf_ws->flags & (RADEON_SURF_IMPORTED | RADEON_SURF_FMASK))) {
?
Marek
I've tried 2 times to be sure. No luck.
Any other idea?
I looked over the code but saw nothing.
Could it be in another file?
Dieter
Addendum:
Bug is here https://bugs.freedesktop.org/show_bug.cgi?id=98518
(so it should be tracked, there?) --- 13.0.0 isn't affected.
Dieter
On Mon, Oct 31, 2016 at 7:21 PM, Dieter Nützel
wrote:
Hello Emil,
if this commit
commit 81a95946dab730c1cfcf04ac1373cea5f7908f65
Author: Marek Olšák
Date: Thu Oct 20 22:57:03 2016 +0200
gallium/radeon: fold radeon_winsys::surface_best into
radeon/winsys
Reviewed-by: Nicolai Hähnle
hits 13.0.0 then I've found an regression on r600g NI/Turks XT.
It show up as texture corruption with FreeCAD (MSAA 8x context) and
under
LS2015 (wine-1.9.21~gallium_nine+staging / MSAA 2+).
I'll open a ticket in some minutes.
How can I switch Mesa master to 13.0.0-rc3, too test?
I'll tried but couldn't found any 13.0.0-rc3 tag.
Thanks,
Dieter
Am 31.10.2016 13:21, schrieb Emil Velikov:
The third release candidate for Mesa 13.0.0 is now available with
the
final
to be out in ~24 hours.
Maintainers, this is a polite reminder to test your respective
drivers
and/or
subsystem. If there are any severe issues with unmerged patches let
me
know and
we'll include them.
Axel Davy (3):
st/nine: Fix leak with integer and boolean constants
st/nine: Fix mistake in Volume9 UnlockBox
st/nine: Fix locking CubeTexture surfaces.
Dave Airlie (1):
radv/ac/llvm: trim texture return values
Emil Velikov (2):
cherry-ignore: add mapi VISILITY_CFLAGS patch
Update version to 13.0.0-rc3
Eric Engestrom (1):
egl/dri2: swap_buffers_with_damage falls back to swap_buffers
Fredrik Höglund (3):
radv: mark the fence as submitted and signalled in
vkAcquireNextImageKHR
vulkan/wsi/x11: fix ARGB window support
vulkan/wsi/wayland: fix ARGB window support
Kenneth Graunke (6):
i965: Drop unnecessary switch statement in nir_setup_outputs()
i965: Make split_virtual_grfs() call compact_virtual_grfs().
i965: Don't use nir_assign_var_locations for VS/TES/GS
outputs.
i965: Drop nir_inputs from fs_visitor.
glsl: Pass ctx to program interface query helper functions.
glsl: Size TCS->TES unsized arrays to gl_MaxPatchVertices for
queries.
Marek Olšák (5):
gallium/radeon: fix incorrect bpe use in
si_set_optimal_micro_tile_mode
gallium/radeon: make sure the address of separate CMASK is
aligned properly
winsys/amdgpu: fix radeon_surf::macro_tile_index for imported
textures
st/mesa: unduplicate st_check_sync code
st/mesa: allow multiple concurrent waiters in ClientWaitSync
Matt Turner (2):
anv: Replace "abi_versions" with correct "api_version".
radv: Replace "abi_versions" with correct "api_version".
Nicolai Hähnle (1):
st/mesa: cleanup and fix primitive restart for indirect draws
Samuel Iglesias Gonsálvez (2):
mesa/program: Add _mesa_symbol_table_replace_symbol()
glsl: update default precision qualifier when it is set in the
shader
Samuel Pitoiset (2):
nvc0: use correct bufctx when invalidating CP textures
nvc0/ir: fix emission of SHLADD with NEG modifiers
Tapani Pälli (5):
egl/dri2: set max values for pbuffer width and height
Revert "egl/android: Set EGL_MAX_PBUFFER_WIDTH and
EGL_MAX_PBUFFER_HEIGHT"
egl: add check that eglCreateContext gets a valid config
mesa: fix error handling in DrawBuffers
egl: set preserved behavior for surface only if config
supports it
Timothy Arceri (1):
glsl/mesa: remove unused namespace support from the symbol
table
git tag: mesa-13.0.0-rc3
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz
MD5: 49923a2add7a026de669b66d4241d6e5 mesa-13.0.0-rc3.tar.gz
SHA1: 358eed62654a472365153687577d0ef04cc8deec
mesa-13.0.0-rc3.tar.gz
SHA256:
99924e8c3c62050b45d160486c94f0efb75ad3ae10890230e1dd154bde86a4b9
mesa-13.0.0-rc3.tar.gz
PGP:
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz.sig
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.xz
MD5: 599f1b7879ee2ca1bd8235f51771b5d0 mesa-13.0.0-rc3.tar.xz
SHA1: bfd7628b36f361e7c6a080169c7be8961da62b6d
mesa-13.0.0-rc3.tar.xz
SHA256:
4a3ec9e93cc2be964e204a591a88d8aa935d988fcba877a56e66441f1ebe681a
mesa-13.0.0-rc3.tar.xz
PGP:
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.xz.sig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] gallium/radeon: Use flags parameter in radeon_winsys_surface_init
Am 02.11.2016 12:11, schrieb Michel Dänzer:
From: Michel Dänzer
Fixes valgrind warnings about surf_ws->flags being uninitialized while
starting X.
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
index 7b85973..6836a1b 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
@@ -228,7 +228,7 @@ static int radeon_winsys_surface_init(struct
radeon_winsys *rws,
surf_winsys_to_drm(&surf_drm, tex, flags, bpe, mode, surf_ws);
-if (!(surf_ws->flags & RADEON_SURF_IMPORTED)) {
+if (!(flags & RADEON_SURF_IMPORTED)) {
r = radeon_surface_best(ws->surf_man, &surf_drm);
if (r)
return r;
Changing this to:
-if (!(surf_ws->flags & RADEON_SURF_IMPORTED)) {
+if (!(flags & (RADEON_SURF_IMPORTED | RADEON_SURF_FMASK))) {
A combination with Marek's idea SOLVED
both (FreeCAD and LS2015 on Wine) for me.
https://bugs.freedesktop.org/show_bug.cgi?id=98518
So you have my
Tested-by: Dieter Nützel
Greetings,
Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 13.0.0-rc3 / CC'ing Mesa-devel
Am 31.10.2016 22:49, schrieb Dieter Nützel:
Am 31.10.2016 22:41, schrieb Dieter Nützel:
Am 31.10.2016 21:22, schrieb Marek Olšák:
Hi,
Hello Marek!
Can you try to replace:
if (!(surf_ws->flags & RADEON_SURF_IMPORTED)) {
with:
if (!(surf_ws->flags & (RADEON_SURF_IMPORTED | RADEON_SURF_FMASK))) {
?
Marek
I've tried 2 times to be sure. No luck.
Any other idea?
I looked over the code but saw nothing.
Could it be in another file?
Dieter
Addendum:
Bug is here https://bugs.freedesktop.org/show_bug.cgi?id=98518
(so it should be tracked, there?) --- 13.0.0 isn't affected.
Dieter
Additional hint from Michel fixed both for me:
-if (!(surf_ws->flags & RADEON_SURF_IMPORTED)) {
+if (!(flags & (RADEON_SURF_IMPORTED | RADEON_SURF_FMASK))) {
Dieter
On Mon, Oct 31, 2016 at 7:21 PM, Dieter Nützel
wrote:
Hello Emil,
if this commit
commit 81a95946dab730c1cfcf04ac1373cea5f7908f65
Author: Marek Olšák
Date: Thu Oct 20 22:57:03 2016 +0200
gallium/radeon: fold radeon_winsys::surface_best into
radeon/winsys
Reviewed-by: Nicolai Hähnle
hits 13.0.0 then I've found an regression on r600g NI/Turks XT.
It show up as texture corruption with FreeCAD (MSAA 8x context) and
under
LS2015 (wine-1.9.21~gallium_nine+staging / MSAA 2+).
I'll open a ticket in some minutes.
How can I switch Mesa master to 13.0.0-rc3, too test?
I'll tried but couldn't found any 13.0.0-rc3 tag.
Thanks,
Dieter
Am 31.10.2016 13:21, schrieb Emil Velikov:
The third release candidate for Mesa 13.0.0 is now available with
the
final
to be out in ~24 hours.
Maintainers, this is a polite reminder to test your respective
drivers
and/or
subsystem. If there are any severe issues with unmerged patches let
me
know and
we'll include them.
Axel Davy (3):
st/nine: Fix leak with integer and boolean constants
st/nine: Fix mistake in Volume9 UnlockBox
st/nine: Fix locking CubeTexture surfaces.
Dave Airlie (1):
radv/ac/llvm: trim texture return values
Emil Velikov (2):
cherry-ignore: add mapi VISILITY_CFLAGS patch
Update version to 13.0.0-rc3
Eric Engestrom (1):
egl/dri2: swap_buffers_with_damage falls back to swap_buffers
Fredrik Höglund (3):
radv: mark the fence as submitted and signalled in
vkAcquireNextImageKHR
vulkan/wsi/x11: fix ARGB window support
vulkan/wsi/wayland: fix ARGB window support
Kenneth Graunke (6):
i965: Drop unnecessary switch statement in
nir_setup_outputs()
i965: Make split_virtual_grfs() call compact_virtual_grfs().
i965: Don't use nir_assign_var_locations for VS/TES/GS
outputs.
i965: Drop nir_inputs from fs_visitor.
glsl: Pass ctx to program interface query helper functions.
glsl: Size TCS->TES unsized arrays to gl_MaxPatchVertices for
queries.
Marek Olšák (5):
gallium/radeon: fix incorrect bpe use in
si_set_optimal_micro_tile_mode
gallium/radeon: make sure the address of separate CMASK is
aligned properly
winsys/amdgpu: fix radeon_surf::macro_tile_index for imported
textures
st/mesa: unduplicate st_check_sync code
st/mesa: allow multiple concurrent waiters in ClientWaitSync
Matt Turner (2):
anv: Replace "abi_versions" with correct "api_version".
radv: Replace "abi_versions" with correct "api_version".
Nicolai Hähnle (1):
st/mesa: cleanup and fix primitive restart for indirect draws
Samuel Iglesias Gonsálvez (2):
mesa/program: Add _mesa_symbol_table_replace_symbol()
glsl: update default precision qualifier when it is set in
the
shader
Samuel Pitoiset (2):
nvc0: use correct bufctx when invalidating CP textures
nvc0/ir: fix emission of SHLADD with NEG modifiers
Tapani Pälli (5):
egl/dri2: set max values for pbuffer width and height
Revert "egl/android: Set EGL_MAX_PBUFFER_WIDTH and
EGL_MAX_PBUFFER_HEIGHT"
egl: add check that eglCreateContext gets a valid config
mesa: fix error handling in DrawBuffers
egl: set preserved behavior for surface only if config
supports it
Timothy Arceri (1):
glsl/mesa: remove unused namespace support from the symbol
table
git tag: mesa-13.0.0-rc3
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz
MD5: 49923a2add7a026de669b66d4241d6e5 mesa-13.0.0-rc3.tar.gz
SHA1: 358eed62654a472365153687577d0ef04cc8deec
mesa-13.0.0-rc3.tar.gz
SHA256:
99924e8c3c62050b45d160486c94f0efb75ad3ae10890230e1dd154bde86a4b9
mesa-13.0.0-rc3.tar.gz
PGP:
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.gz.sig
https://mesa.freedesktop.org/archive/13.0.0/mesa-13.0.0-rc3.tar.xz
MD5: 599f1b7879ee2ca1bd8235f51771b5d0 mesa-13.0.0-rc3.tar.xz
SHA1: bfd7628b36f361e7c6a080169c7be8961da62b6d
mesa-13.0.0-rc3.tar.xz
SHA256:
4a3ec9e93cc2be964e204a591a88d8aa935d988fcba877a56e66441f1ebe681a
mesa-13.0.0-rc3.tar.xz
PGP:
https://m
Re: [Mesa-dev] [PATCH] pipe-loader: add libamd_common for radeonsi
Tested-by: Dieter Nützel Argh, should read, please go ahead and commit. ;-) Dieter Am 03.11.2016 15:28, schrieb Nicolai Hähnle: From: Nicolai Hähnle This fixes a build regression of commit 7115e56c21ace07cf04f5073ba73a533e2182099. Sorry for the breakage, this second location for link dependencies escaped my build tests. --- src/gallium/targets/pipe-loader/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/targets/pipe-loader/Makefile.am b/src/gallium/targets/pipe-loader/Makefile.am index 18b403f..ce504cf 100644 --- a/src/gallium/targets/pipe-loader/Makefile.am +++ b/src/gallium/targets/pipe-loader/Makefile.am @@ -151,20 +151,21 @@ if HAVE_GALLIUM_RADEONSI pipe_LTLIBRARIES += pipe_radeonsi.la pipe_radeonsi_la_SOURCES = pipe_radeonsi.c nodist_EXTRA_pipe_radeonsi_la_SOURCES = dummy.cpp pipe_radeonsi_la_LIBADD = \ $(PIPE_LIBS) \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(top_builddir)/src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.la \ $(top_builddir)/src/gallium/drivers/radeon/libradeon.la \ $(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \ + $(top_builddir)/src/amd/common/libamd_common.la \ $(LIBDRM_LIBS) \ $(RADEON_LIBS) \ $(AMDGPU_LIBS) endif if HAVE_GALLIUM_FREEDRENO pipe_LTLIBRARIES += pipe_msm.la pipe_msm_la_SOURCES = pipe_msm.c ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] pipe-loader: add libamd_common for radeonsi
Tested-by: Dieter Nützel Am 03.11.2016 15:28, schrieb Nicolai Hähnle: From: Nicolai Hähnle This fixes a build regression of commit 7115e56c21ace07cf04f5073ba73a533e2182099. Sorry for the breakage, this second location for link dependencies escaped my build tests. --- src/gallium/targets/pipe-loader/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/targets/pipe-loader/Makefile.am b/src/gallium/targets/pipe-loader/Makefile.am index 18b403f..ce504cf 100644 --- a/src/gallium/targets/pipe-loader/Makefile.am +++ b/src/gallium/targets/pipe-loader/Makefile.am @@ -151,20 +151,21 @@ if HAVE_GALLIUM_RADEONSI pipe_LTLIBRARIES += pipe_radeonsi.la pipe_radeonsi_la_SOURCES = pipe_radeonsi.c nodist_EXTRA_pipe_radeonsi_la_SOURCES = dummy.cpp pipe_radeonsi_la_LIBADD = \ $(PIPE_LIBS) \ $(top_builddir)/src/gallium/winsys/radeon/drm/libradeonwinsys.la \ $(top_builddir)/src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.la \ $(top_builddir)/src/gallium/drivers/radeon/libradeon.la \ $(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \ + $(top_builddir)/src/amd/common/libamd_common.la \ $(LIBDRM_LIBS) \ $(RADEON_LIBS) \ $(AMDGPU_LIBS) endif if HAVE_GALLIUM_FREEDRENO pipe_LTLIBRARIES += pipe_msm.la pipe_msm_la_SOURCES = pipe_msm.c ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] clover: Add CL_PROGRAM_BINARY_TYPE support (CL1.2).
After latest clover commit 'luxmark-v3.0' sigfault immediately: SOURCE/luxmark-v3.0> ./luxmark ./luxmark.bin: /usr/local/lib/libOpenCL.so.1: no version information available (required by ./luxmark.bin) *** Error in `./luxmark.bin': corrupted double-linked list: 0x7f51a57829e0 *** === Backtrace: = /lib64/libc.so.6(+0x727df)[0x7f51e49847df] /lib64/libc.so.6(+0x7804e)[0x7f51e498a04e] /lib64/libc.so.6(+0x782d4)[0x7f51e498a2d4] /lib64/libc.so.6(+0x78d01)[0x7f51e498ad01] /usr/local/lib/libOpenCL.so.1(+0x20b418)[0x7f51e53d7418] /usr/local/lib/libOpenCL.so.1(+0x20bcc7)[0x7f51e53d7cc7] /usr/local/lib/libOpenCL.so.1(clReleaseMemObject+0x40)[0x7f51e53ba700] ./luxmark.bin(_ZN3slg23PathOCLBaseRenderThread13FreeOCLBufferEPPN2cl6BufferE+0x52)[0x7bfb92] ./luxmark.bin(_ZN3slg23PathOCLBaseRenderThread4StopEv+0x6c)[0x7c3f0c] ./luxmark.bin(_ZN3slg19PathOCLRenderThread4StopEv+0x9)[0x701a09] ./luxmark.bin(_ZN3slg23PathOCLBaseRenderEngine12StopLockLessEv+0x97)[0x7bba07] ./luxmark.bin(_ZN3slg12RenderEngine4StopEv+0x26)[0x666a26] ./luxmark.bin(_ZN3slg13RenderSessionD1Ev+0x7e)[0x658e8e] ./luxmark.bin(_ZN7luxcore13RenderSessionD1Ev+0x22)[0x5e5502] ./luxmark.bin[0x5e1db2] ./luxmark.bin[0x5c69a4] ./luxmark.bin[0x5c6b6f] ./luxmark.bin[0x5cf6de] ./luxmark.bin[0x86e83c] ./luxmark.bin[0x8742d7] ./luxmark.bin[0xf981ad] ./luxmark.bin[0xf9a770] ./luxmark.bin[0xfbb67f] ./luxmark.bin[0x8ed424] ./luxmark.bin[0xf9705f] ./luxmark.bin[0xf9735e] ./luxmark.bin[0xf9b58b] ./luxmark.bin[0x5ad82a] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f51e4933b05] ./luxmark.bin[0x5bea37] === Memory map: 0040-01e7f000 r-xp 09:00 1054819 /tmp/INSTALL/SOURCE/luxmark-v3.0/luxmark.bin 0207f000-020f5000 r--p 01a7f000 09:00 1054819 /tmp/INSTALL/SOURCE/luxmark-v3.0/luxmark.bin 020f5000-0000 rw-p 01af5000 09:00 1054819 /tmp/INSTALL/SOURCE/luxmark-v3.0/luxmark.bin 0000-02284000 rw-p 00:00 0 02882000-03246000 rw-p 00:00 0 [heap] 7f519bfde000-7f51a400 rw-p 00:00 0 7f51a400-7f51a7ff8000 rw-p 00:00 0 7f51a7ff8000-7f51a800 ---p 00:00 0 7f51a8855000-7f51a9219000 rw-s 12cb3b000 00:06 13357 /dev/dri/renderD128 7f51a9219000-7f51ac00 rw-p 00:00 0 7f51ac00-7f51ac0e3000 rw-p 00:00 0 7f51ac0e3000-7f51b000 ---p 00:00 0 7f51b000-7f51b00e4000 rw-p 00:00 0 7f51b00e4000-7f51b400 ---p 00:00 0 7f51b400-7f51b40e3000 rw-p 00:00 0 7f51b40e3000-7f51b800 ---p 00:00 0 7f51b8217000-7f51baffe000 rw-p 00:00 0 7f51baffe000-7f51bafff000 ---p 00:00 0 7f51bafff000-7f51bb7ff000 rw-p 00:00 0 7f51bb7ff000-7f51bb80 ---p 00:00 0 7f51bb80-7f51bc00 rw-p 00:00 0 7f51bc00-7f51bc0e3000 rw-p 00:00 0 7f51bc0e3000-7f51c000 ---p 00:00 0 7f51c000-7f51c00e3000 rw-p 00:00 0 7f51c00e3000-7f51c400 ---p 00:00 0 7f51c400-7f51c40e3000 rw-p 00:00 0 7f51c40e3000-7f51c800 ---p 00:00 0 7f51c800-7f51c80e3000 rw-p 00:00 0 7f51c80e3000-7f51cc00 ---p 00:00 0 7f51cc00-7f51cc0e3000 rw-p 00:00 0 7f51cc0e3000-7f51d000 ---p 00:00 0 7f51d0216000-7f51d0217000 ---p 00:00 0 7f51d0217000-7f51d0a17000 rw-p 00:00 0 7f51d1218000-7f51d400 rw-p 00:00 0 7f51d400-7f51d7ef8000 rw-p 00:00 0 7f51d7ef8000-7f51d800 ---p 00:00 0 7f51d8962000-7f51d8963000 ---p 00:00 0 7f51d8963000-7f51d9163000 rw-p 00:00 0 7f51d9163000-7f51d9164000 ---p 00:00 0 7f51d9164000-7f51d9964000 rw-p 00:00 0 7f51d9964000-7f51d9965000 ---p 00:00 0 7f51d9965000-7f51da165000 rw-p 00:00 0 7f51da165000-7f51da166000 ---p 00:00 0 7f51da166000-7f51da966000 rw-p 00:00 0 7f51da966000-7f51da967000 ---p 00:00 0 7f51da967000-7f51db167000 rw-p 00:00 0 7f51db167000-7f51db168000 ---p 00:00 0 7f51db168000-7f51db968000 rw-p 00:00 0 7f51dbcb1000-7f51dbd5b000 r--p 09:00 4983414 /usr/share/fonts/truetype/DejaVuSans-Bold.ttf 7f51dbd5b000-7f51dbd5c000 ---p 00:00 0 7f51dbd5c000-7f51dc55c000 rw-p 00:00 0 7f51dc55c000-7f51dc55d000 ---p 00:00 0 7f51dc55d000-7f51dcd5d000 rw-p 00:00 0 7f51dcd5d000-7f51dcd5e000 ---p 00:00 0 7f51dcd5e000-7f51dd55e000 rw-p 00:00 0 7f51dd55e000-7f51dd56 r-xp 09:00 3554964 /usr/lib64/libXinerama.so.1.0.0 7f51dd56-7f51dd75f000 ---p 2000 09:00 3554964 /usr/lib64/libXinerama.so.1.0.0 7f51dd75f000-7f51dd76 r--p 1000 09:00 3554964 /usr/lib64/libXinerama.so.1.0.0 7f51dd76-7f51dd761000 rw-p 2000 09:00 3554964 /
[Mesa-dev] Next Mesa git build error wit latest LLVM version (4.0.0svn).
Tried LLVM version 4.0.0svn (after Tom's and Aaron's fixes), today. I had to go back to version from 2. Nov. Thanks, Dieter make[3]: Entering directory '/opt/mesa/src/amd/common' CC ac_nir_to_llvm.lo ac_nir_to_llvm.c:145:43: error: unknown type name 'LLVMAttribute' unsigned param_count, LLVMAttribute attribs); ^ ac_nir_to_llvm.c: In function 'create_llvm_function': ac_nir_to_llvm.c:231:4: error: implicit declaration of function 'LLVMAddAttribute' [-Werror=implicit-function-declaration] LLVMAddAttribute(P, LLVMByValAttribute); ^ ac_nir_to_llvm.c:231:24: error: 'LLVMByValAttribute' undeclared (first use in this function) LLVMAddAttribute(P, LLVMByValAttribute); ^ ac_nir_to_llvm.c:231:24: note: each undeclared identifier is reported only once for each function it appears in ac_nir_to_llvm.c:235:24: error: 'LLVMInRegAttribute' undeclared (first use in this function) LLVMAddAttribute(P, LLVMInRegAttribute); ^ ac_nir_to_llvm.c: In function 'emit_intrin_1f_param': ac_nir_to_llvm.c:711:2: error: implicit declaration of function 'emit_llvm_intrinsic' [-Werror=implicit-function-declaration] return emit_llvm_intrinsic(ctx, intrin, ctx->f32, params, 1, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c:711:63: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) return emit_llvm_intrinsic(ctx, intrin, ctx->f32, params, 1, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_intrin_2f_param': ac_nir_to_llvm.c:722:63: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) return emit_llvm_intrinsic(ctx, intrin, ctx->f32, params, 2, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_intrin_3f_param': ac_nir_to_llvm.c:734:63: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) return emit_llvm_intrinsic(ctx, intrin, ctx->f32, params, 3, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_find_lsb': ac_nir_to_llvm.c:760:72: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) return emit_llvm_intrinsic(ctx, "llvm.cttz.i32", ctx->i32, params, 2, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_ifind_msb': ac_nir_to_llvm.c:768:13: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_ufind_msb': ac_nir_to_llvm.c:794:13: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_ffract': ac_nir_to_llvm.c:858:8: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_uint_carry': ac_nir_to_llvm.c:874:18: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) params, 2, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_bitfield_extract': ac_nir_to_llvm.c:919:63: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) result = emit_llvm_intrinsic(ctx, intrin, ctx->i32, srcs, 3, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'get_thread_id': ac_nir_to_llvm.c:1026:21: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) tid_args, 2, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'emit_ddxy': ac_nir_to_llvm.c:1118:7: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: In function 'visit_alu': ac_nir_to_llvm.c:1454:78: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) result = emit_llvm_intrinsic(ctx, "llvm.bitreverse.i32", ctx->i32, src, 1, LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c: At top level: ac_nir_to_llvm.c:1585:43: error: unknown type name 'LLVMAttribute' unsigned param_count, LLVMAttribute attribs) ^ ac_nir_to_llvm.c: In function 'radv_lower_gather4_integer': ac_nir_to_llvm.c:1683:9: error: 'LLVMReadNoneAttribute' undeclared (first use in this function) LLVMReadNoneAttribute); ^ ac_nir_to_llvm.c:1707:32: error: 'LLVMNoUnwindAttribute' undeclared (first use in this function) LLVMReadNoneAttribute | LLVMNoUnwindAttribute); ^ ac_nir_to_llvm.c: In function 'build_tex_intrinsic': ac_nir_to_llv
Re: [Mesa-dev] clover: Add CL_PROGRAM_BINARY_TYPE support (CL1.2).
Am 08.11.2016 21:16, schrieb Serge Martin: On Sunday 06 November 2016 17:02:26 Dieter Nützel wrote: After latest clover commit 'luxmark-v3.0' sigfault immediately: Hello Did you bisect it? Luxmark seems to crash just the same here without this commit. Serge Hello Serge, yes, of course (that's why I wrote 'latest clover commit') ;-) But, it seems to be LLVM (4.0.0svn) related?! With updated LLVM version 4.0.0svn (before ~23:15 last night!, some commits after that do not compile for me) it works with _this_ commit, as before. E.g. I think the speed has improved over time. Greetings, Dieter SOURCE/luxmark-v3.0> ./luxmark ./luxmark.bin: /usr/local/lib/libOpenCL.so.1: no version information available (required by ./luxmark.bin) *** Error in `./luxmark.bin': corrupted double-linked list: 0x7f51a57829e0 ***___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Clover] Compilations error with latest LLVM version 4.0.0svn in llvm/codegen/bitcode.cpp
Hello Francisco, next little change needed. Thanks, Dieter make[4]: Entering directory '/opt/mesa/src/gallium/state_trackers/clover' CXX llvm/codegen/libclllvm_la-bitcode.lo llvm/codegen/bitcode.cpp: In function 'std::unique_ptr clover::llvm::parse_module_library(const clover::module&, llvm::LLVMContext&, std::string&)': llvm/codegen/bitcode.cpp:102:50: error: 'class llvm::Expected >' has no member named 'getError' fail(r_log, error(CL_INVALID_PROGRAM), mod.getError().message()); ^ In file included from ./llvm/metadata.hpp:31:0, from llvm/codegen/bitcode.cpp:35: ./llvm/compat.hpp: At global scope: ./llvm/compat.hpp:157:21: warning: 'clover::llvm::compat::default_reloc_model' defined but not used [-Wunused-variable] const auto default_reloc_model = ::llvm::None; ^ Makefile:900: recipe for target 'llvm/codegen/libclllvm_la-bitcode.lo' failed make[4]: *** [llvm/codegen/libclllvm_la-bitcode.lo] Error 1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: adapt to new error API since LLVM r286752
Tested-by: Dieter Nützel
Thanks Vedran!
Dieter
Am 14.11.2016 12:17, schrieb Vedran Miletić:
---
src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp | 10
--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 8e89a49..5dcc4f8 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -98,8 +98,14 @@ clover::llvm::parse_module_library(const module &m,
::llvm::LLVMContext &ctx,
std::string &r_log) {
auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
as_string(m.secs[0].data), "
"), ctx);
- if (!mod)
- fail(r_log, error(CL_INVALID_PROGRAM),
mod.getError().message());
+
+ if (::llvm::Error err = mod.takeError()) {
+ std::string msg;
+ ::llvm::handleAllErrors(std::move(err),
[&](::llvm::ErrorInfoBase &EIB) {
+ msg = EIB.message();
+ fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
+ });
+ }
return std::unique_ptr<::llvm::Module>(std::move(*mod));
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [AppVeyor] mesa master #2862 failed
Hello Timothy, it fails, here: state_tracker/st_atom_texture.c: In function 'update_textures': state_tracker/st_atom_texture.c:130:49: error: 'const struct ' has no member named 'data' prog->sh.data->Version); ^ Greetings, Dieter Am 02.12.2016 04:15, schrieb AppVeyor: BUILD MESA 2862 FAILED [1] Commit 6bf63b0119 by Timothy Arceri on 11/9/2016 4:01 AM: st/mesa: get Version from gl_program rather than gl_shader_program\n\nReviewed-by: Nicolai Hähnle Configure your notification preferences [2] Links: -- [1] https://ci.appveyor.com/project/jrfonseca-fdo/mesa/build/2862 [2] https://ci.appveyor.com/notifications ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/84] Introduce gallium nine internal multithreading
Am 07.12.2016 23:54, schrieb Axel Davy: This patch adds internal multithreading to gallium nine. The goal is to offload almost all gallium nine calls (and some other work) to a worker thread. Hello Axel, really nice job! 'But' show us the 'numbers'... ...do you have some numbers of hand? Thanks, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Congrats AMD-Team! --- RX480 + Mesa-git + 4.7-rcX
Well done! Best wishes. Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] clover: compilation error with former LLVM 3.9.0svn and current LLVM 4.0.0svn
/opt/opencl-example> llc --version
LLVM (http://llvm.org/):
LLVM version 4.0.0svn
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: nehalem
Registered Targets:
amdgcn - AMD GCN GPUs
r600 - AMD GPUs HD2XXX-HD6XXX
x86- 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
make[4]: Entering directory
'/opt/mesa/src/gallium/state_trackers/clover'
CXX llvm/codegen/libclllvm_la-native.lo
llvm/codegen/native.cpp: In function 'std::vector
{anonymous}::emit_code(llvm::Module&, const clover::llvm::target&,
llvm::TargetMachine::CodeGenFileType, std::string&)':
llvm/codegen/native.cpp:129:52: error: invalid initialization of
non-const reference of type
'clover::llvm::compat::raw_ostream_to_emit_file {aka
llvm::raw_svector_ostream&}' from an rvalue of type 'initializer list>'
compat::raw_ostream_to_emit_file fos { os };
^
Makefile:914: recipe for target 'llvm/codegen/libclllvm_la-native.lo'
failed
make[4]: *** [llvm/codegen/libclllvm_la-native.lo] Error 1
make[4]: Leaving directory '/opt/mesa/src/gallium/state_trackers/clover'
Makefile:594: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/opt/mesa/src/gallium'
Makefile:700: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/opt/mesa/src'
Makefile:574: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/opt/mesa/src'
Makefile:640: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: make older c++ (4.8.x) happy
Signed-off-by: Dieter Nützel
---
src/gallium/state_trackers/clover/llvm/codegen/native.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index b96236b..f5e887e 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -126,7 +126,7 @@ namespace {
{
compat::pass_manager pm;
::llvm::raw_svector_ostream os { data };
- compat::raw_ostream_to_emit_file fos { os };
+ compat::raw_ostream_to_emit_file fos ( os );
mod.setDataLayout(compat::get_data_layout(*tm));
tm->Options.MCOptions.AsmVerbose =
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Patch v2] clover: make GCC 4.8 happy
Without this GCC 4.8.x throws below error:
error: invalid initialization of non-const reference of type
'clover::llvm::compat::raw_ostream_to_emit_file {aka
llvm::raw_svector_ostream&}'
from an rvalue of type ''
v2: change commit title and add error message like Eric Engestrom requested
Signed-off-by: Dieter Nützel
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97019
---
src/gallium/state_trackers/clover/llvm/codegen/native.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index b96236b..f5e887e 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -126,7 +126,7 @@ namespace {
{
compat::pass_manager pm;
::llvm::raw_svector_ostream os { data };
- compat::raw_ostream_to_emit_file fos { os };
+ compat::raw_ostream_to_emit_file fos ( os );
mod.setDataLayout(compat::get_data_layout(*tm));
tm->Options.MCOptions.AsmVerbose =
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Patch v2] clover: make GCC 4.8 happy
Can someone of you commit for me after review, please.
Thanks,
Dieter
Am 28.07.2016 00:20, schrieb Dieter Nützel:
Without this GCC 4.8.x throws below error:
error: invalid initialization of non-const reference of type
'clover::llvm::compat::raw_ostream_to_emit_file {aka
llvm::raw_svector_ostream&}'
from an rvalue of type ''
v2: change commit title and add error message like Eric Engestrom
requested
Signed-off-by: Dieter Nützel
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97019
---
src/gallium/state_trackers/clover/llvm/codegen/native.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
index b96236b..f5e887e 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/native.cpp
@@ -126,7 +126,7 @@ namespace {
{
compat::pass_manager pm;
::llvm::raw_svector_ostream os { data };
- compat::raw_ostream_to_emit_file fos { os };
+ compat::raw_ostream_to_emit_file fos ( os );
mod.setDataLayout(compat::get_data_layout(*tm));
tm->Options.MCOptions.AsmVerbose =
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730
Hello Christian, after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with my RV730 (AGP). All nice videos didn't play any longer. -Dieter BTW I'm not on Mesa Devel, so please CC me. /opt/mesa> vdpauinfo display: :0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types --- 420 8192 8192 NV12 YV12 422 8192 8192 UYVY YUYV 444 8192 8192 Y8U8V8A8 V8U8Y8A8 Decoder capabilities: name level macbs width height --- MPEG1 0 262144 8192 8192 MPEG2_SIMPLE 3 262144 8192 8192 MPEG2_MAIN3 262144 8192 8192 Output surface: name width height nat types B8G8R8A8 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 R8G8B8A8 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 R10G10B10A2 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 B10G10R10A2 8192 8192y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 Bitmap surface: name width height -- B8G8R8A8 8192 8192 R8G8B8A8 8192 8192 R10G10B10A2 8192 8192 B10G10R10A2 8192 8192 A88192 8192 Video mixer: feature namesup DEINTERLACE_TEMPORAL - DEINTERLACE_TEMPORAL_SPATIAL - INVERSE_TELECINE - NOISE_REDUCTION y SHARPNESSy LUMA_KEY - HIGH QUALITY SCALING - L1- HIGH QUALITY SCALING - L2- HIGH QUALITY SCALING - L3- HIGH QUALITY SCALING - L4- HIGH QUALITY SCALING - L5- HIGH QUALITY SCALING - L6- HIGH QUALITY SCALING - L7- HIGH QUALITY SCALING - L8- HIGH QUALITY SCALING - L9- parameter name sup min max - VIDEO_SURFACE_WIDTH y48 8192 VIDEO_SURFACE_HEIGHT y48 8192 CHROMA_TYPE y LAYERS y 04 attribute name sup min max - BACKGROUND_COLOR y CSC_MATRIX y NOISE_REDUCTION_LEVELy 0.00 1.00 SHARPNESS_LEVEL y -1.00 1.00 LUMA_KEY_MIN_LUMAy LUMA_KEY_MAX_LUMAy Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed! (I've only have libvdpau1-0.6 not 0.7 on openSUSE 12.3.) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730
Am 30.09.2013 10:47, schrieb Grigori Goronzy: On 30.09.2013 10:06, Michel Dänzer wrote: On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote: after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with my RV730 (AGP). Same problem on PALM. Bisection shows that it is caused by commit 68f6dec32. The initialization order seems to be wrong, the check for UVD is done too early. I'll send a patch in a minute. Best regards Grigori Thank you Grigori and Marek (AMD!) ;-) -Dieter That probably means you lost UVD support for some reason. Assuming UVD is still enabled in the kernel, can you bisect which Mesa change caused the problem for you? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] radeon: Write-combined CPU mappings of BOs in GTT
Am 18.07.2014 05:07, schrieb Michel Dänzer: On 17.07.2014 19:09, Christian König wrote: Am 17.07.2014 12:01, schrieb Michel Dänzer: In order to try and improve X(Shm)PutImage performance with glamor, I implemented support for write-combined CPU mappings of BOs in GTT. This did provide a nice speedup, but to my surprise, using VRAM instead of write-combined GTT turned out to be even faster in general on my Kaveri machine, both for the internal GPU and for discrete GPUs. However, I've kept the changes from GTT to VRAM separated, in case this turns out to be a loss on other setups. Kernel patches: [PATCH 1/5] drm/radeon: Remove radeon_gart_restore() [PATCH 2/5] drm/radeon: Pass GART page flags to [PATCH 3/5] drm/radeon: Allow write-combined CPU mappings of BOs in [PATCH 4/5] drm/radeon: Use write-combined CPU mappings of rings and Those four are Reviewed-by: Christian König Thanks! [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI I'm still not very keen with this change since I still don't understand the reason why it's faster than with GTT. Definitely needs more testing on a wider range of systems. Sure. If anyone wants to give this patch a spin and see if they can measure any performance difference, good or bad, that would be interesting. Maybe limit it to APUs for now? But IIRC, CPU writes to VRAM vs. write-combined GTT are actually an even bigger win with dedicated GPUs than with the Kaveri built-in GPU on my system. I suspect it may depend on the bandwidth available for PCIe vs. system memory though. Michel, please, please do NOT change anything on this!;-) You all know that I currently can only run this on my poor Duron 1800 with RV730 (AGP), but... With this all 'objview' demos (mesa-demos) run at 60 fps (vsync), even with chip set/CPU power management enabled (athcool on). If I set vblank_mode=0 the slowest GreatLakesBiplaneHP.obj run at ~100 fps (~16 fps before) => 6x speedup. (Even 5 planes run at 30 fps) - Wow!!! 'buddha' went from ~40 fps up to ~175 fps 'bunny' went from ~60 fps up to ~215 fps 'bobcat' show not such a big improvement 'only' 70 fps more R600_HYPERZ=1 help somewhat, too but not in all cases. Overall X/Kwin eXperience is much better. Let me know which benchmarks you need. Cheers, Dieter BTW Do anyone know how I can override BIOS GTT settings? I can only set 256 MB max. - BIOS patching? With agpmode=-1 I can run with 1024 MB GTT ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds
Hello Ian, hello Timothy,
does this fix the regression introduced with commit fb78fa58?
[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
initTexture2D (bisected)
http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html
Thanks,
Dieter
Am 01.04.2014 22:15, schrieb Ian Romanick:
From: Ian Romanick
Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
GL_KHR_debug output functions. As a result, the function names in
struct _glapi_table also changed. The table in check_table.cpp used
the
ARB names.
Signed-off-by: Ian Romanick
Cc: Vinson Lee
Cc: Timothy Arceri
---
src/mapi/glapi/tests/check_table.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mapi/glapi/tests/check_table.cpp
b/src/mapi/glapi/tests/check_table.cpp
index 375645b..89d9073 100644
--- a/src/mapi/glapi/tests/check_table.cpp
+++ b/src/mapi/glapi/tests/check_table.cpp
@@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
{ "glGetShaderPrecisionFormat", _O(GetShaderPrecisionFormat) },
{ "glReleaseShaderCompiler", _O(ReleaseShaderCompiler) },
{ "glShaderBinary", _O(ShaderBinary) },
- { "glDebugMessageCallbackARB", _O(DebugMessageCallbackARB) },
- { "glDebugMessageControlARB", _O(DebugMessageControlARB) },
- { "glDebugMessageInsertARB", _O(DebugMessageInsertARB) },
- { "glGetDebugMessageLogARB", _O(GetDebugMessageLogARB) },
+ { "glDebugMessageCallback", _O(DebugMessageCallback) },
+ { "glDebugMessageControl", _O(DebugMessageControl) },
+ { "glDebugMessageInsert", _O(DebugMessageInsert) },
+ { "glGetDebugMessageLog", _O(GetDebugMessageLog) },
{ "glGetGraphicsResetStatusARB", _O(GetGraphicsResetStatusARB) },
{ "glGetnColorTableARB", _O(GetnColorTableARB) },
{ "glGetnCompressedTexImageARB", _O(GetnCompressedTexImageARB) },
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds
Am 02.04.2014 08:12, schrieb Timothy Arceri:
On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:
Hello Ian, hello Timothy,
does this fix the regression introduced with commit fb78fa58?
[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
initTexture2D (bisected)
http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html
Thanks,
Dieter
Hi Dieter,
I just ran ./build/Release/gl-320-primitive-sprite on Mesa 10.2.0-devel
(git-76ba50a) on Intel graphics and it ran fine with no error. Have you
tried running it again with the latest code from git?
Tim
Hello Tim,
thank you very much for your direct reply!
I've retested it with Mesa git daily on my _32bit_ system.
All with same result.
I even recompiled ogl-samples after recheckout several times NO go.
Last try last night 8-(
But,
...argh,
after your request I've cloned ogl-samples this evening again and can't
compile it anylonger. Someone changed the code to compile on 64 bit
system only now, I think:
[ 13%] Building CXX object
framework/CMakeFiles/framework.dir/compiler.cpp.o
Linking CXX static library libframework.a
[ 13%] Built target framework
Scanning dependencies of target es-200-draw-elements
[ 13%] Building CXX object
tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o
Linking CXX executable ../build/Release/es-200-draw-elements
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
skipping incompatible
/opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when
searching for -lfreeimage
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
cannot find -lfreeimage
collect2: error: ld returned 1 exit status
make[2]: *** [build/Release/es-200-draw-elements] Fehler 1
make[1]: *** [tests/CMakeFiles/es-200-draw-elements.dir/all] Fehler 2
make: *** [all] Fehler 2
69.267u 4.505s 1:27.26 84.5%0+0k 12368+11176io 44pf+0w
I'll try to go back some days in ogl-samples repository and try to get
it running (with Mesa 10.1.0), again as starting point.
Any hints?
-Dieter
Am 01.04.2014 22:15, schrieb Ian Romanick:
> From: Ian Romanick
>
> Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
> GL_KHR_debug output functions. As a result, the function names in
> struct _glapi_table also changed. The table in check_table.cpp used
> the
> ARB names.
>
> Signed-off-by: Ian Romanick
> Cc: Vinson Lee
> Cc: Timothy Arceri
> ---
> src/mapi/glapi/tests/check_table.cpp | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mapi/glapi/tests/check_table.cpp
> b/src/mapi/glapi/tests/check_table.cpp
> index 375645b..89d9073 100644
> --- a/src/mapi/glapi/tests/check_table.cpp
> +++ b/src/mapi/glapi/tests/check_table.cpp
> @@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
> { "glGetShaderPrecisionFormat", _O(GetShaderPrecisionFormat) },
> { "glReleaseShaderCompiler", _O(ReleaseShaderCompiler) },
> { "glShaderBinary", _O(ShaderBinary) },
> - { "glDebugMessageCallbackARB", _O(DebugMessageCallbackARB) },
> - { "glDebugMessageControlARB", _O(DebugMessageControlARB) },
> - { "glDebugMessageInsertARB", _O(DebugMessageInsertARB) },
> - { "glGetDebugMessageLogARB", _O(GetDebugMessageLogARB) },
> + { "glDebugMessageCallback", _O(DebugMessageCallback) },
> + { "glDebugMessageControl", _O(DebugMessageControl) },
> + { "glDebugMessageInsert", _O(DebugMessageInsert) },
> + { "glGetDebugMessageLog", _O(GetDebugMessageLog) },
> { "glGetGraphicsResetStatusARB", _O(GetGraphicsResetStatusARB) },
> { "glGetnColorTableARB", _O(GetnColorTableARB) },
> { "glGetnCompressedTexImageARB", _O(GetnCompressedTexImageARB) },
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds
Am 03.04.2014 01:19, schrieb Ian Romanick:
On 04/02/2014 03:43 PM, Dieter Nützel wrote:
Am 02.04.2014 08:12, schrieb Timothy Arceri:
On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote:
Hello Ian, hello Timothy,
does this fix the regression introduced with commit fb78fa58?
[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION):
initTexture2D (bisected)
http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html
Thanks,
Dieter
Hi Dieter,
I just ran ./build/Release/gl-320-primitive-sprite on Mesa
10.2.0-devel
(git-76ba50a) on Intel graphics and it ran fine with no error. Have
you
tried running it again with the latest code from git?
Tim
Hello Tim,
thank you very much for your direct reply!
I've retested it with Mesa git daily on my _32bit_ system.
All with same result.
I even recompiled ogl-samples after recheckout several times NO go.
Last try last night 8-(
But,
...argh,
after your request I've cloned ogl-samples this evening again and
can't
compile it anylonger. Someone changed the code to compile on 64 bit
system only now, I think:
[ 13%] Building CXX object
framework/CMakeFiles/framework.dir/compiler.cpp.o
Linking CXX static library libframework.a
[ 13%] Built target framework
Scanning dependencies of target es-200-draw-elements
[ 13%] Building CXX object
tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o
Linking CXX executable ../build/Release/es-200-draw-elements
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
skipping incompatible
/opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when
searching for -lfreeimage
He's shipping a prebuilt .a??? Madness!
It seems so ;-(
Is there source code for FreeImage included?
Can't find any.
Can you just build a 32-bit version?
I see only linux64.
It seems like he has a crazy build system...
/opt/ogl-samples> l external/FreeImage-3.15.4/*
-rw-r--r-- 1 dieter users 53617 3. Apr 00:25
external/FreeImage-3.15.4/FreeImage.h
external/FreeImage-3.15.4/linux64:
insgesamt 6424
drwxr-xr-x 2 dieter users4096 3. Apr 01:16 .
drwxr-xr-x 6 dieter users4096 3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 6877852 3. Apr 01:16 libfreeimage.a
external/FreeImage-3.15.4/macosx:
insgesamt 9592
drwxr-xr-x 2 dieter users 4096 3. Apr 01:16 .
drwxr-xr-x 6 dieter users 4096 3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 10397040 3. Apr 01:16 libfreeimage.a
external/FreeImage-3.15.4/win32:
insgesamt 2452
drwxr-xr-x 2 dieter users4096 3. Apr 00:25 .
drwxr-xr-x 6 dieter users4096 3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 2732032 3. Apr 00:25 FreeImage.dll
-rw-r--r-- 1 dieter users 64482 3. Apr 00:25 FreeImage.lib
external/FreeImage-3.15.4/win64:
insgesamt 3208
drwxr-xr-x 2 dieter users4096 3. Apr 00:25 .
drwxr-xr-x 6 dieter users4096 3. Apr 01:16 ..
-rw-r--r-- 1 dieter users 3508736 3. Apr 00:25 FreeImage.dll
-rw-r--r-- 1 dieter users 60368 3. Apr 00:25 FreeImage.lib
Worked all OK before 18. March 2014.
Tried several older versions but no success at the moment.
git checkout `git rev-list -n 1 --before="2014-03-18" master`
-Dieter
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld:
cannot find -lfreeimage
collect2: error: ld returned 1 exit status
make[2]: *** [build/Release/es-200-draw-elements] Fehler 1
make[1]: *** [tests/CMakeFiles/es-200-draw-elements.dir/all] Fehler 2
make: *** [all] Fehler 2
69.267u 4.505s 1:27.26 84.5%0+0k 12368+11176io 44pf+0w
I'll try to go back some days in ogl-samples repository and try to get
it running (with Mesa 10.1.0), again as starting point.
Any hints?
-Dieter
Am 01.04.2014 22:15, schrieb Ian Romanick:
> From: Ian Romanick
>
> Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the
> GL_KHR_debug output functions. As a result, the function names in
> struct _glapi_table also changed. The table in check_table.cpp used
> the
> ARB names.
>
> Signed-off-by: Ian Romanick
> Cc: Vinson Lee
> Cc: Timothy Arceri
> ---
> src/mapi/glapi/tests/check_table.cpp | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mapi/glapi/tests/check_table.cpp
> b/src/mapi/glapi/tests/check_table.cpp
> index 375645b..89d9073 100644
> --- a/src/mapi/glapi/tests/check_table.cpp
> +++ b/src/mapi/glapi/tests/check_table.cpp
> @@ -1227,10 +1227,10 @@ const struct name_offset known_dispatch[] = {
> { "glGetShaderPrecisionFormat", _O(GetShaderPrecisionFormat) },
> { "glReleaseShaderCompiler", _O(ReleaseShaderCompiler) },
> { "glShaderBinary", _O(ShaderBinary) },
> - { "glDebugMessageCallbackARB", _O(DebugMessageCallbackARB) },
> - { "glDebugMessageControlARB", _O(DebugMessageControlARB) },
> - { "glDebugMessageInsertARB", _O(DebugMessageInsertARB)
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds
Am 03.04.2014 01:19, schrieb Ian Romanick: On 04/02/2014 03:43 PM, Dieter Nützel wrote: Am 02.04.2014 08:12, schrieb Timothy Arceri: On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote: Hello Ian, hello Timothy, does this fix the regression introduced with commit fb78fa58? [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D (bisected) http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html Thanks, Dieter Hi Dieter, I just ran ./build/Release/gl-320-primitive-sprite on Mesa 10.2.0-devel (git-76ba50a) on Intel graphics and it ran fine with no error. Have you tried running it again with the latest code from git? Tim Hello Tim, thank you very much for your direct reply! I've retested it with Mesa git daily on my _32bit_ system. All with same result. I even recompiled ogl-samples after recheckout several times NO go. Last try last night 8-( But, ...argh, after your request I've cloned ogl-samples this evening again and can't compile it anylonger. Someone changed the code to compile on 64 bit system only now, I think: [ 13%] Building CXX object framework/CMakeFiles/framework.dir/compiler.cpp.o Linking CXX static library libframework.a [ 13%] Built target framework Scanning dependencies of target es-200-draw-elements [ 13%] Building CXX object tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o Linking CXX executable ../build/Release/es-200-draw-elements /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: skipping incompatible /opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when searching for -lfreeimage He's shipping a prebuilt .a??? Madness! Is there source code for FreeImage included? Can you just build a 32-bit version? It seems like he has a crazy build system... Thank you guys for your patience... I'll try to go back some days in ogl-samples repository and try to get it running (with Mesa 10.1.0), again as starting point. Due to git clone -b 4.4.0 https://github.com/g-truc/ogl-samples I'm back to ogl-samples 4.4.0 (without FreeImage-3.15.4) and set, now. Mesa 10.1.0: OK /opt/ogl-samples> glxinfo | grep OpenGL libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No such file or directory) OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.1.0 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No such file or directory) OpenGL Version Needed 3.2 ( 3.3 Found ) Compiling shader gl-320/primitive-sprite.vert... Compiling shader gl-320/primitive-sprite.frag... Linking program Running Test Test Ended Test Began Correctly. Mesa 10.2.0-devel (git-d120506): BAD /opt/ogl-samples> glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-d120506) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-d120506) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: /opt/ogl-samples> ./build/release/gl-320-primitive-sprite OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D Running Test Test Ended Any ideas? BTW gl-320-primitive-shading sigfault with Mesa 10.1.0 and show OpenGL Error(GL_INVALID_OPERATION): initProgram with Mesa 10.2.0-devel (git-d120506) on r600g. What does (should) it look like on Intel? Dieter Am 01.04.2014 22:15, schrieb Ian Romanick: > From: Ian Romanick > > Commit fb78fa58 made the GL_ARB_debug_output functions aliases of the > GL_KHR_debug output functions. As a result, the function names in > struct _glapi_table also changed. The table in check_table.cpp used > the > ARB names. > > Signed-off-by: Ian Romanick > Cc: Vinson Lee > Cc: Timothy Arceri > --- > src/mapi/glapi/tests/check_table.cpp | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/mapi/glapi/tests/check_table.cpp > b/src/mapi/glapi/tests/check_table.cpp > index 375645b..89d9073 100644 > --- a/src/mapi/glapi/tests/check_table.cpp > +++ b/src/mapi/glapi/tests/check_table.cpp > @@ -1
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds
Am 03.04.2014 04:16, schrieb Ian Romanick: On 04/02/2014 06:13 PM, Dieter Nützel wrote: Am 03.04.2014 01:19, schrieb Ian Romanick: On 04/02/2014 03:43 PM, Dieter Nützel wrote: Am 02.04.2014 08:12, schrieb Timothy Arceri: On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote: Hello Ian, hello Timothy, does this fix the regression introduced with commit fb78fa58? [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D (bisected) http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html Thanks, Dieter Hi Dieter, I just ran ./build/Release/gl-320-primitive-sprite on Mesa 10.2.0-devel (git-76ba50a) on Intel graphics and it ran fine with no error. Have you tried running it again with the latest code from git? Tim Hello Tim, thank you very much for your direct reply! I've retested it with Mesa git daily on my _32bit_ system. All with same result. I even recompiled ogl-samples after recheckout several times NO go. Last try last night 8-( But, ...argh, after your request I've cloned ogl-samples this evening again and can't compile it anylonger. Someone changed the code to compile on 64 bit system only now, I think: [ 13%] Building CXX object framework/CMakeFiles/framework.dir/compiler.cpp.o Linking CXX static library libframework.a [ 13%] Built target framework Scanning dependencies of target es-200-draw-elements [ 13%] Building CXX object tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o Linking CXX executable ../build/Release/es-200-draw-elements /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: skipping incompatible /opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when searching for -lfreeimage He's shipping a prebuilt .a??? Madness! Is there source code for FreeImage included? Can you just build a 32-bit version? It seems like he has a crazy build system... Thank you guys for your patience... I'll try to go back some days in ogl-samples repository and try to get it running (with Mesa 10.1.0), again as starting point. Due to git clone -b 4.4.0 https://github.com/g-truc/ogl-samples I'm back to ogl-samples 4.4.0 (without FreeImage-3.15.4) and set, now. Mesa 10.1.0: OK /opt/ogl-samples> glxinfo | grep OpenGL libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No such file or directory) OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.1.0 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No such file or directory) OpenGL Version Needed 3.2 ( 3.3 Found ) Compiling shader gl-320/primitive-sprite.vert... Compiling shader gl-320/primitive-sprite.frag... Linking program Running Test Test Ended Test Began Correctly. Mesa 10.2.0-devel (git-d120506): BAD /opt/ogl-samples> glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-d120506) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-d120506) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: /opt/ogl-samples> ./build/release/gl-320-primitive-sprite OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D I'm guessing that initTexture2D is in the application. Can you set a breakpoint at _mesa_error to see where exactly Mesa is throwing GL_INVALID_OPERATION. That should shed some light on things. Ian, can you please guide me a bit. running gdb ./build/release/gl-320-primitive-sprite and (gdb) break _mesa_error Function "_mesa_error" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (_mesa_error) pending. Do not do the trick. Running Test Test Ended Any ideas? BTW gl-320-primitive-shading sigfault with Mesa 10.1.0 and show OpenGL Error(GL_INVALID_OPERATION): initProgram with Mesa 10.2.0-devel (git-d120506) on r600g. What does (should) it look like on Intel? Had this (geom shader) anybody running? How should it look like? Maybe a picture? I did all of this to get a picture about the r600g geom shader glory... ...sadly there is NO 32 bit versio
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds
Am 03.04.2014 22:53, schrieb Ian Romanick: On 04/03/2014 07:35 AM, Dieter Nützel wrote: Am 03.04.2014 04:16, schrieb Ian Romanick: On 04/02/2014 06:13 PM, Dieter Nützel wrote: Am 03.04.2014 01:19, schrieb Ian Romanick: On 04/02/2014 03:43 PM, Dieter Nützel wrote: Am 02.04.2014 08:12, schrieb Timothy Arceri: On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote: Hello Ian, hello Timothy, does this fix the regression introduced with commit fb78fa58? [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D (bisected) http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html Thanks, Dieter Hi Dieter, I just ran ./build/Release/gl-320-primitive-sprite on Mesa 10.2.0-devel (git-76ba50a) on Intel graphics and it ran fine with no error. Have you tried running it again with the latest code from git? Tim Hello Tim, thank you very much for your direct reply! I've retested it with Mesa git daily on my _32bit_ system. All with same result. I even recompiled ogl-samples after recheckout several times NO go. Last try last night 8-( But, ...argh, after your request I've cloned ogl-samples this evening again and can't compile it anylonger. Someone changed the code to compile on 64 bit system only now, I think: [ 13%] Building CXX object framework/CMakeFiles/framework.dir/compiler.cpp.o Linking CXX static library libframework.a [ 13%] Built target framework Scanning dependencies of target es-200-draw-elements [ 13%] Building CXX object tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o Linking CXX executable ../build/Release/es-200-draw-elements /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: skipping incompatible /opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a when searching for -lfreeimage He's shipping a prebuilt .a??? Madness! Is there source code for FreeImage included? Can you just build a 32-bit version? It seems like he has a crazy build system... Thank you guys for your patience... I'll try to go back some days in ogl-samples repository and try to get it running (with Mesa 10.1.0), again as starting point. Due to git clone -b 4.4.0 https://github.com/g-truc/ogl-samples I'm back to ogl-samples 4.4.0 (without FreeImage-3.15.4) and set, now. Mesa 10.1.0: OK /opt/ogl-samples> glxinfo | grep OpenGL libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No such file or directory) OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.0 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.1.0 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No such file or directory) OpenGL Version Needed 3.2 ( 3.3 Found ) Compiling shader gl-320/primitive-sprite.vert... Compiling shader gl-320/primitive-sprite.frag... Linking program Running Test Test Ended Test Began Correctly. Mesa 10.2.0-devel (git-d120506): BAD /opt/ogl-samples> glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-d120506) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-d120506) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: /opt/ogl-samples> ./build/release/gl-320-primitive-sprite OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D I'm guessing that initTexture2D is in the application. Can you set a breakpoint at _mesa_error to see where exactly Mesa is throwing GL_INVALID_OPERATION. That should shed some light on things. Ian, can you please guide me a bit. running gdb ./build/release/gl-320-primitive-sprite and (gdb) break _mesa_error Function "_mesa_error" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (_mesa_error) pending. Do not do the trick. But you still get the error from the application? Eh... I'm at a loss, then. _mesa_error is *the* function in Mesa that sets GL errors. MESA_DEBUG=verbose give any output? Failing that... valgrind? Does this help? setenv MESA_DEBUG verbose (tcsh ;-) Mesa 10.2.0-devel (git-c6050ce) /opt/ogl-samples> ./bu
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds
Am 04.04.2014 04:06, schrieb Timothy Arceri: On Friday, 4 April 2014 11:31 AM, Dieter Nützel wrote: Mesa 10.2.0-devel (git-c6050ce) /opt/ogl-samples> ./build/release/gl-320-primitive-sprite Mesa warning: failed to remap glDebugMessageCallbackARB Mesa warning: failed to remap glDebugMessageControlARB Mesa warning: failed to remap glDebugMessageInsertARB Mesa warning: failed to remap glGetDebugMessageLogARB Have you tried doing a 'make clean' on Mesa and rebuilding? For sure. 'make clean' | 'make distclean' | several new checkout (git clone mesa...) But I did it, again to no avail. It looks like something is not quite right with the dispatch table. I saw that. Could it be, that I use the Mesa 10.1.0 gl.h file during ogl-samples compilation? - It differs from the Mesa 10.2.0-devel gl.h version. /opt/mesa> diff /usr/include/GL/gl.h /opt/mesa/include/GL/gl.h 697c697 < #define GL_ALL_ATTRIB_BITS0x000F --- #define GL_ALL_ATTRIB_BITS0x It's so confusing, only ogl-samples didn't work since your fb78fa58 commit. (my git bisect result) -Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] glapi: Fix build break in 'make check' on non-shared-glapi builds - SOLVED
Am 05.04.2014 08:04, schrieb Timothy Arceri: On Fri, 2014-04-04 at 17:40 -0700, Ian Romanick wrote: On 04/03/2014 05:31 PM, Dieter Nützel wrote: > Am 03.04.2014 22:53, schrieb Ian Romanick: >> On 04/03/2014 07:35 AM, Dieter Nützel wrote: >>> Am 03.04.2014 04:16, schrieb Ian Romanick: >>>> On 04/02/2014 06:13 PM, Dieter Nützel wrote: >>>>> Am 03.04.2014 01:19, schrieb Ian Romanick: >>>>>> On 04/02/2014 03:43 PM, Dieter Nützel wrote: >>>>>>> Am 02.04.2014 08:12, schrieb Timothy Arceri: >>>>>>>> On Wed, 2014-04-02 at 00:56 +0200, Dieter Nützel wrote: >>>>>>>>> Hello Ian, hello Timothy, >>>>>>>>> >>>>>>>>> does this fix the regression introduced with commit fb78fa58? >>>>>>>>> >>>>>>>>> [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): >>>>>>>>> initTexture2D (bisected) >>>>>>>>> http://lists.freedesktop.org/archives/mesa-dev/2014-March/056165.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>>Dieter >>>>>>>> >>>>>>>> Hi Dieter, >>>>>>>> >>>>>>>> I just ran ./build/Release/gl-320-primitive-sprite on Mesa >>>>>>>> 10.2.0-devel >>>>>>>> (git-76ba50a) on Intel graphics and it ran fine with no error. >>>>>>>> Have you >>>>>>>> tried running it again with the latest code from git? >>>>>>>> Tim >>>>>>> >>>>>>> Hello Tim, >>>>>>> >>>>>>> thank you very much for your direct reply! >>>>>>> I've retested it with Mesa git daily on my _32bit_ system. >>>>>>> All with same result. >>>>>>> I even recompiled ogl-samples after recheckout several times NO go. >>>>>>> Last try last night 8-( >>>>>>> >>>>>>> But, >>>>>>> >>>>>>> ...argh, >>>>>>> after your request I've cloned ogl-samples this evening again and >>>>>>> can't >>>>>>> compile it anylonger. Someone changed the code to compile on 64 bit >>>>>>> system only now, I think: >>>>>>> >>>>>>> [ 13%] Building CXX object >>>>>>> framework/CMakeFiles/framework.dir/compiler.cpp.o >>>>>>> Linking CXX static library libframework.a >>>>>>> [ 13%] Built target framework >>>>>>> Scanning dependencies of target es-200-draw-elements >>>>>>> [ 13%] Building CXX object >>>>>>> tests/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o >>>>>>> Linking CXX executable ../build/Release/es-200-draw-elements >>>>>>> /usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: >>>>>>> skipping incompatible >>>>>>> /opt/ogl-samples/external/FreeImage-3.15.4/linux64/libfreeimage.a >>>>>>> when >>>>>>> searching for -lfreeimage >>>>>> >>>>>> He's shipping a prebuilt .a??? Madness! Is there source code for >>>>>> FreeImage included? Can you just build a 32-bit version? It seems >>>>>> like >>>>>> he has a crazy build system... >>>>> >>>>> Thank you guys for your patience... >>>>> >>>>>>> I'll try to go back some days in ogl-samples repository and try >>>>>>> to get >>>>>>> it running (with Mesa 10.1.0), again as starting point. >>>>> >>>>> Due to >>>>> git clone -b 4.4.0 https://github.com/g-truc/ogl-samples >>>>> I'm back to ogl-samples 4.4.0 (without FreeImage-3.15.4) >>>>> and set, now. >>>>> >>>>> Mesa 10.1.0: OK >>>>> >>>>> /opt/ogl-samples> glxinfo | grep OpenGL >>>>> libGL error: dlopen /usr/lib/dri/updates/r600_dri.so failed >>>>> (/usr/lib/dri/updates/r600_dri.so: cannot open shared object file: No >>>>> such file or directory) >>>>> OpenGL vendor string: X.O
Re: [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D
Am 17.03.2014 19:07, schrieb Marek Olšák: It would be good to know what's causing the error, so that we can rule out the possibility that the test is wrong and Mesa is right. Marek Hello Marek, Tim and Ian helped me a lot to find a solution. Look here: http://lists.freedesktop.org/archives/mesa-dev/2014-April/057699.html Maybe you have an idea what is it really. Cheers, Dieter (My night beer after a hard day in our forest. Computer science went into the back for several years, now) ;-) On Mon, Mar 17, 2014 at 3:34 PM, Dieter Nützel wrote: Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP. /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL: screen 0 does not appear to be DRI3 capable libGL: pci id for fd 4: 1002:9495, driver r600 libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so libGL: driver does not expose __driDriverGetExtensions_r600(): /usr/lib/dri/updates/r600_dri.so: undefined symbol: __driDriverGetExtensions_r600 libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D Running Test Test Ended Worked OK ~10 days ago. When I run Mesa 10.1.0 final, it is OK. OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-7e0396d) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7e0396d) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: Thanks, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] MesaCVS: Current compiler warnnings
Making all in builtin_compiler gmake[4]: Entering directory `/opt/mesa/src/glsl/builtin_compiler' CXX glsl_lexer.lo glsl_lexer.cpp: In function 'int yy_get_next_buffer(yyscan_t)': glsl_lexer.cpp:3076:3: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] CXX link_uniforms.lo ../../../src/glsl/link_uniforms.cpp: In function 'void link_update_uniform_buffer_variables(gl_shader*)': ../../../src/glsl/link_uniforms.cpp:567:37: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] CC vbo_exec_api.lo ../../src/mesa/vbo/vbo_exec_api.c: In function 'vbo_exec_fixup_vertex': ../../src/mesa/vbo/vbo_exec_api.c:338:8: warning: '*((void *)&tmp+12)' may be used uninitialized in this function [-Wmaybe-uninitialized] ../../src/mesa/vbo/vbo_exec_api.c:334:16: note: '*((void *)&tmp+12)' was declared here ../../src/mesa/vbo/vbo_exec_api.c:338:8: warning: '*((void *)&tmp+8)' may be used uninitialized in this function [-Wmaybe-uninitialized] ../../src/mesa/vbo/vbo_exec_api.c:334:16: note: '*((void *)&tmp+8)' was declared here ../../src/mesa/vbo/vbo_exec_api.c:338:8: warning: '*((void *)&tmp+4)' may be used uninitialized in this function [-Wmaybe-uninitialized] ../../src/mesa/vbo/vbo_exec_api.c:334:16: note: '*((void *)&tmp+4)' was declared here ../../src/mesa/vbo/vbo_exec_api.c:338:8: warning: 'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized] ../../src/mesa/vbo/vbo_exec_api.c:334:16: note: 'tmp' was declared here CC draw/draw_gs.lo draw/draw_gs.c: In function 'draw_create_geometry_shader': draw/draw_gs.c:805:33: warning: 'llvm_gs' may be used uninitialized in this function [-Wmaybe-uninitialized] CXX gallivm/lp_bld_debug.lo gallivm/lp_bld_debug.cpp: In member function 'virtual void raw_debug_ostream::write_impl(const char*, size_t)': gallivm/lp_bld_debug.cpp:116:40: warning: cast from type 'const char*' to type 'char*' casts away qualifiers [-Wcast-qual] CC radeon_drm_cs_dump.lo radeon_drm_cs_dump.c: In function 'radeon_dump_cs_on_lockup': radeon_drm_cs_dump.c:104:21: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t' [-Wformat] radeon_drm_cs_dump.c:147:21: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'uint64_t' [-Wformat] radeon_drm_cs_dump.c:150:21: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'uint64_t' [-Wformat] Cheers, Dieter -- Please CC me, I'm not on the list. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D
Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP. /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL: screen 0 does not appear to be DRI3 capable libGL: pci id for fd 4: 1002:9495, driver r600 libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so libGL: driver does not expose __driDriverGetExtensions_r600(): /usr/lib/dri/updates/r600_dri.so: undefined symbol: __driDriverGetExtensions_r600 libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D Running Test Test Ended Worked OK ~10 days ago. When I run Mesa 10.1.0 final, it is OK. OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-7e0396d) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7e0396d) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: Thanks, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D
Am 17.03.2014 18:59, schrieb Benjamin Bellec: Hi, Could you bisect? It's under way... Or provide an easy way to build ogl-samples! There was a post on dri-devel 've used. Bug tracker look, here: Bug 74717 - r600g: 'invalid read' linking geometry shader https://bugs.freedesktop.org/show_bug.cgi?id=74717 [-] To reproduce using the source code: $ git clone https://github.com/g-truc/ogl-samples $ cmake . $ make $ build/build/release/gl-320-primitive-shading [-] build/release/gl-320-primitive-shading OR build/release/gl-320-primitive-sprite Greetings. Regards. Le 17/03/2014 15:34, Dieter Nützel a écrit : Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP. /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL: screen 0 does not appear to be DRI3 capable libGL: pci id for fd 4: 1002:9495, driver r600 libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so libGL: driver does not expose __driDriverGetExtensions_r600(): /usr/lib/dri/updates/r600_dri.so: undefined symbol: __driDriverGetExtensions_r600 libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D Running Test Test Ended Worked OK ~10 days ago. When I run Mesa 10.1.0 final, it is OK. OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-7e0396d) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7e0396d) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: Thanks, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D (bisected)
Am 17.03.2014 21:55, schrieb Dieter Nützel: Am 17.03.2014 18:59, schrieb Benjamin Bellec: Hi, Could you bisect? It's under way... Here we go: /opt/mesa> git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [6c3f5abc2dc99a904994fb41d6e48527ddcdf7de] mesa: add missing DebugMessageControl types /opt/mesa> git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [fb78fa58d2a60110bfd428ca8d41b746b69b6724] mesa: make ARB_debug_output functions an alias of KHR_debug /opt/mesa> git bisect bad fb78fa58d2a60110bfd428ca8d41b746b69b6724 is the first bad commit commit fb78fa58d2a60110bfd428ca8d41b746b69b6724 Author: Timothy Arceri Date: Sat Mar 8 15:35:54 2014 +1100 mesa: make ARB_debug_output functions an alias of KHR_debug Also update dispatch sanity removing ARB_debug_output checks and removing KHR_debug placeholders as the checks have already been added V2: Make sure we exit case statements with conditional breaks rather than just dropping through. Signed-off-by: Timothy Arceri Reviewed-by: Brian Paul :04 04 d4366b822a2f8882cde4256aa3272e2cb1a80802 551586f1fc86259f2e1c9b9ccc93c3c93942f08c M src BAD 7e0396d 5ecdd7b 45ee1b3 1308d21 6c3f5ab fb78fa5 GOOD171ec95 6d2dffe a1b189a 0608d34 If I only get my dual CPU system running, again... Have fun! Or provide an easy way to build ogl-samples! There was a post on dri-devel 've used. Bug tracker look, here: Bug 74717 - r600g: 'invalid read' linking geometry shader https://bugs.freedesktop.org/show_bug.cgi?id=74717 [-] To reproduce using the source code: $ git clone https://github.com/g-truc/ogl-samples $ cmake . $ make $ build/build/release/gl-320-primitive-shading [-] build/release/gl-320-primitive-shading OR build/release/gl-320-primitive-sprite Greetings. Regards. Le 17/03/2014 15:34, Dieter Nützel a écrit : Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP. /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL: screen 0 does not appear to be DRI3 capable libGL: pci id for fd 4: 1002:9495, driver r600 libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so libGL: driver does not expose __driDriverGetExtensions_r600(): /usr/lib/dri/updates/r600_dri.so: undefined symbol: __driDriverGetExtensions_r600 libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D Running Test Test Ended Worked OK ~10 days ago. When I run Mesa 10.1.0 final, it is OK. OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-7e0396d) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7e0396d) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: Thanks, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D (bisected)
FWIW, I'm on a pure 32 bit system. Dieter Am 18.03.2014 04:24, schrieb Dieter Nützel: Am 17.03.2014 21:55, schrieb Dieter Nützel: Am 17.03.2014 18:59, schrieb Benjamin Bellec: Hi, Could you bisect? It's under way... Here we go: /opt/mesa> git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [6c3f5abc2dc99a904994fb41d6e48527ddcdf7de] mesa: add missing DebugMessageControl types /opt/mesa> git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [fb78fa58d2a60110bfd428ca8d41b746b69b6724] mesa: make ARB_debug_output functions an alias of KHR_debug /opt/mesa> git bisect bad fb78fa58d2a60110bfd428ca8d41b746b69b6724 is the first bad commit commit fb78fa58d2a60110bfd428ca8d41b746b69b6724 Author: Timothy Arceri Date: Sat Mar 8 15:35:54 2014 +1100 mesa: make ARB_debug_output functions an alias of KHR_debug Also update dispatch sanity removing ARB_debug_output checks and removing KHR_debug placeholders as the checks have already been added V2: Make sure we exit case statements with conditional breaks rather than just dropping through. Signed-off-by: Timothy Arceri Reviewed-by: Brian Paul :04 04 d4366b822a2f8882cde4256aa3272e2cb1a80802 551586f1fc86259f2e1c9b9ccc93c3c93942f08c M src BAD 7e0396d 5ecdd7b 45ee1b3 1308d21 6c3f5ab fb78fa5 GOOD171ec95 6d2dffe a1b189a 0608d34 If I only get my dual CPU system running, again... Have fun! Or provide an easy way to build ogl-samples! There was a post on dri-devel 've used. Bug tracker look, here: Bug 74717 - r600g: 'invalid read' linking geometry shader https://bugs.freedesktop.org/show_bug.cgi?id=74717 [-] To reproduce using the source code: $ git clone https://github.com/g-truc/ogl-samples $ cmake . $ make $ build/build/release/gl-320-primitive-shading [-] build/release/gl-320-primitive-shading OR build/release/gl-320-primitive-sprite Greetings. Regards. Le 17/03/2014 15:34, Dieter Nützel a écrit : Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP. /opt/ogl-samples> ./build/release/gl-320-primitive-sprite libGL: screen 0 does not appear to be DRI3 capable libGL: pci id for fd 4: 1002:9495, driver r600 libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so libGL: driver does not expose __driDriverGetExtensions_r600(): /usr/lib/dri/updates/r600_dri.so: undefined symbol: __driDriverGetExtensions_r600 libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. libGL: Can't open configuration file /home/dieter/.drirc: No such file or directory. OpenGL Version Needed 3.2 ( 3.3 Found ) OpenGL Error(GL_INVALID_OPERATION): initTexture2D Running Test Test Ended Worked OK ~10 days ago. When I run Mesa 10.1.0 final, it is OK. OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-7e0396d) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7e0396d) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: Thanks, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/radeon: increase the size of buffer cache
Am 12.01.2015 16:00, schrieb Marek Olšák: From: Marek Olšák This should fix this performance regression: https://bugs.freedesktop.org/show_bug.cgi?id=88227 --- src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c index 75fc80f..72b7931 100644 --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c @@ -673,7 +673,7 @@ radeon_drm_winsys_create(int fd, radeon_screen_create_t screen_create) goto fail; ws->cman = pb_cache_manager_create(ws->kman, 100, 2.0f, 0, - (ws->info.vram_size + ws->info.gart_size) / 8); + MIN2(ws->info.vram_size, ws->info.gart_size)); if (!ws->cman) goto fail; Marek will you commit? Works here so far on RV730 (AGP). Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA
Am 12.02.2019 00:40, schrieb Dieter Nützel: Sorry that I step in so late, but the whole family recover slowly from a bad flu... Tried your 'latest" three series altogether with my Polaris 20 (NIR!). UH and UV hang after some seconds reliable. VM faults. Have to dig deeper in (remote) to get some logs. UH [47001.185090] amdgpu :01:00.0: GPU fault detected: 147 0x0b384801 for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586 [47001.185094] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0373EF67 [47001.185096] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001 [47001.185098] amdgpu :01:00.0: VM fault (0x01, vmid 3, pasid 32786) at page 57929575, read from 'TC4' (0x54433400) (72) [47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=11380701, emitted seq=11380703 [47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [47011.401787] amdgpu :01:00.0: GPU reset begin! [47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:49:crtc-0] hw_done or flip_done timed out But my reported Polaris triangle corruptions are solved, now. W'll try to verify which patches fixed it. Look here: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079319-running-the-radeonsi-nir-back-end-with-mesa-19-1-git?p=1079390#post1079390 Greetings, Dieter Am 07.02.2019 02:21, schrieb Marek Olšák: Hi, This patch series increases radeonsi performance in some cases. glxgears performance decreases slightly. Visible VRAM is usually congested due to CPU accesses, which cause buffers to be evicted from that part of VRAM. This removes the congestion for all data pushed into const_uploader. We have had many problems with const_uploader slowing stuff down due to visible VRAM congestion. The most recent one is this Starcraft 2 issue report on github: https://github.com/iXit/Mesa-3D/issues/333 Since const_uploader reuses buffers from the winsys buffer cache, the odds are that the reused buffers are already evicted, so the first use is usually slower due to higher shader load latencies. This series uses SDMA to get constants into VRAM, so it doesn't have any of the above drawbacks. SC2 numbers with various other methods (from the github issue report): - originally: 50-55 fps - changing const_uploader to STREAM: 75-80 fps - use stream_uploader for constants in Nine: 90 fps - this series: 105-110 fps Trivial benchmarks such as glxgears can expect 20% decrease in performance due to the added cost of the SDMA CS ioctl that wasn't there before. CPU-bound apps with many IBs are almost unaffected thanks to winsys multithreading. Feedback welcome, Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA
Am 12.02.2019 03:22, schrieb Dieter Nützel: Am 12.02.2019 00:40, schrieb Dieter Nützel: Sorry that I step in so late, but the whole family recover slowly from a bad flu... Tried your 'latest" three series altogether with my Polaris 20 (NIR!). UH and UV hang after some seconds reliable. VM faults. Have to dig deeper in (remote) to get some logs. UH [47001.185090] amdgpu :01:00.0: GPU fault detected: 147 0x0b384801 for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586 [47001.185094] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0373EF67 [47001.185096] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001 [47001.185098] amdgpu :01:00.0: VM fault (0x01, vmid 3, pasid 32786) at page 57929575, read from 'TC4' (0x54433400) (72) [47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=11380701, emitted seq=11380703 [47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [47011.401787] amdgpu :01:00.0: GPU reset begin! [47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:49:crtc-0] hw_done or flip_done timed out These GPU faults are SOLVED after reverting the SDMA (1-4) series. But my reported Polaris triangle corruptions are solved, now. These reported (last year) triangle corruptions are SOLVED _before_ all of these patches. GREAT! W'll try to verify which patches fixed it. If I have more time then I'll try to find the corresponding patch/fix. Cheers, Dieter Look here: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079319-running-the-radeonsi-nir-back-end-with-mesa-19-1-git?p=1079390#post1079390 Greetings, Dieter Am 07.02.2019 02:21, schrieb Marek Olšák: Hi, This patch series increases radeonsi performance in some cases. glxgears performance decreases slightly. Visible VRAM is usually congested due to CPU accesses, which cause buffers to be evicted from that part of VRAM. This removes the congestion for all data pushed into const_uploader. We have had many problems with const_uploader slowing stuff down due to visible VRAM congestion. The most recent one is this Starcraft 2 issue report on github: https://github.com/iXit/Mesa-3D/issues/333 Since const_uploader reuses buffers from the winsys buffer cache, the odds are that the reused buffers are already evicted, so the first use is usually slower due to higher shader load latencies. This series uses SDMA to get constants into VRAM, so it doesn't have any of the above drawbacks. SC2 numbers with various other methods (from the github issue report): - originally: 50-55 fps - changing const_uploader to STREAM: 75-80 fps - use stream_uploader for constants in Nine: 90 fps - this series: 105-110 fps Trivial benchmarks such as glxgears can expect 20% decrease in performance due to the added cost of the SDMA CS ioctl that wasn't there before. CPU-bound apps with many IBs are almost unaffected thanks to winsys multithreading. Feedback welcome, Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: re-initialize query buffers if they are reused
Tested-by: Dieter Nützel
Calmed mostly some hiccups with Rocket League which our son found around
XMass on Polaris. All was fine after additional Mesa git clean ups.
Thanks,
Dieter
Am 26.01.2019 01:58, schrieb Marek Olšák:
From: Marek Olšák
Fixes: e0f0d3675d4 "radeonsi: factor si_query_buffer logic out of
si_query_hw"
---
src/gallium/drivers/radeonsi/si_query.c | 20
src/gallium/drivers/radeonsi/si_query.h | 1 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_query.c
b/src/gallium/drivers/radeonsi/si_query.c
index 266b9d3ce84..c115e7787b2 100644
--- a/src/gallium/drivers/radeonsi/si_query.c
+++ b/src/gallium/drivers/radeonsi/si_query.c
@@ -542,34 +542,46 @@ void si_query_buffer_reset(struct si_context
*sctx, struct si_query_buffer *buff
while (buffer->previous) {
struct si_query_buffer *qbuf = buffer->previous;
buffer->previous = qbuf->previous;
si_resource_reference(&buffer->buf, NULL);
buffer->buf = qbuf->buf; /* move ownership */
FREE(qbuf);
}
buffer->results_end = 0;
+ if (!buffer->buf)
+ return;
+
/* Discard even the oldest buffer if it can't be mapped without a
stall. */
- if (buffer->buf &&
- (si_rings_is_buffer_referenced(sctx, buffer->buf->buf,
RADEON_USAGE_READWRITE) ||
- !sctx->ws->buffer_wait(buffer->buf->buf, 0,
RADEON_USAGE_READWRITE))) {
+ if (si_rings_is_buffer_referenced(sctx, buffer->buf->buf,
RADEON_USAGE_READWRITE) ||
+ !sctx->ws->buffer_wait(buffer->buf->buf, 0,
RADEON_USAGE_READWRITE)) {
si_resource_reference(&buffer->buf, NULL);
+ } else {
+ /* Re-initialize it before begin. */
+ buffer->prepare_buffer_before_begin = true;
}
}
bool si_query_buffer_alloc(struct si_context *sctx, struct
si_query_buffer *buffer,
bool (*prepare_buffer)(struct si_context *, struct
si_query_buffer*),
unsigned size)
{
- if (buffer->buf && buffer->results_end + size >=
buffer->buf->b.b.width0)
+ if (buffer->buf && buffer->results_end + size >=
buffer->buf->b.b.width0) {
+ if (buffer->prepare_buffer_before_begin &&
+ prepare_buffer && unlikely(!prepare_buffer(sctx, buffer))) {
+ si_resource_reference(&buffer->buf, NULL);
+ return false;
+ }
+ buffer->prepare_buffer_before_begin = false;
return true;
+ }
if (buffer->buf) {
struct si_query_buffer *qbuf = MALLOC_STRUCT(si_query_buffer);
memcpy(qbuf, buffer, sizeof(*qbuf));
buffer->previous = qbuf;
}
buffer->results_end = 0;
/* Queries are normally read by the CPU after
diff --git a/src/gallium/drivers/radeonsi/si_query.h
b/src/gallium/drivers/radeonsi/si_query.h
index aaf0bd03aca..be393c2fbd2 100644
--- a/src/gallium/drivers/radeonsi/si_query.h
+++ b/src/gallium/drivers/radeonsi/si_query.h
@@ -170,20 +170,21 @@ struct si_query_hw_ops {
struct si_resource *buffer, uint64_t va);
void (*clear_result)(struct si_query_hw *, union pipe_query_result
*);
void (*add_result)(struct si_screen *screen,
struct si_query_hw *, void *buffer,
union pipe_query_result *result);
};
struct si_query_buffer {
/* The buffer where query results are stored. */
struct si_resource *buf;
+ boolprepare_buffer_before_begin;
/* Offset of the next free result after current query data */
unsignedresults_end;
/* If a query buffer is full, a new buffer is created and the old one
* is put in here. When we calculate the result, we sum up the
samples
* from all buffers. */
struct si_query_buffer *previous;
};
void si_query_buffer_destroy(struct si_screen *sctx, struct
si_query_buffer *buffer);
void si_query_buffer_reset(struct si_context *sctx, struct
si_query_buffer *buffer);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: use compute for clear_render_target when possible
Maybe rebase?
Dieter
Am 24.01.2019 00:28, schrieb Marek Olšák:
From: Sonny Jiang
Signed-off-by: Sonny Jiang
Signed-off-by: Marek Olšák
---
src/gallium/drivers/radeonsi/si_clear.c | 6 ++
.../drivers/radeonsi/si_compute_blit.c| 96 +++
src/gallium/drivers/radeonsi/si_pipe.c| 4 +
src/gallium/drivers/radeonsi/si_pipe.h| 9 ++
.../drivers/radeonsi/si_shaderlib_tgsi.c | 69 +
5 files changed, 184 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_clear.c
b/src/gallium/drivers/radeonsi/si_clear.c
index b3910a4651c..8afc01f2ccc 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -664,20 +664,26 @@ static void si_clear(struct pipe_context *ctx,
unsigned buffers,
}
static void si_clear_render_target(struct pipe_context *ctx,
struct pipe_surface *dst,
const union pipe_color_union *color,
unsigned dstx, unsigned dsty,
unsigned width, unsigned height,
bool render_condition_enabled)
{
struct si_context *sctx = (struct si_context *)ctx;
+ struct si_texture *sdst = (struct si_texture*)dst->texture;
+
+ if (dst->texture->nr_samples <= 1 && !sdst->dcc_offset) {
+ si_compute_clear_render_target(ctx, dst, color, dstx, dsty, width,
height);
+ return;
+ }
si_blitter_begin(sctx, SI_CLEAR_SURFACE |
(render_condition_enabled ? 0 :
SI_DISABLE_RENDER_COND));
util_blitter_clear_render_target(sctx->blitter, dst, color,
dstx, dsty, width, height);
si_blitter_end(sctx);
}
static void si_clear_depth_stencil(struct pipe_context *ctx,
struct pipe_surface *dst,
diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c
b/src/gallium/drivers/radeonsi/si_compute_blit.c
index 38c48c30be9..f06497f4dac 100644
--- a/src/gallium/drivers/radeonsi/si_compute_blit.c
+++ b/src/gallium/drivers/radeonsi/si_compute_blit.c
@@ -18,20 +18,21 @@
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT
SHALL
* THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
* DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
OR
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*
*/
#include "si_pipe.h"
#include "util/u_format.h"
+#include "util/format_srgb.h"
/* Note: Compute shaders always use SI_COMPUTE_DST_CACHE_POLICY for
dst
* and L2_STREAM for src.
*/
static enum si_cache_policy get_cache_policy(struct si_context *sctx,
enum si_coherency coher,
uint64_t size)
{
if ((sctx->chip_class >= GFX9 && (coher == SI_COHERENCY_CB_META ||
coher == SI_COHERENCY_CP)) ||
@@ -418,10 +419,105 @@ void si_compute_copy_image(struct si_context
*sctx,
ctx->bind_compute_state(ctx, saved_cs);
ctx->set_shader_images(ctx, PIPE_SHADER_COMPUTE, 0, 2, saved_image);
ctx->set_constant_buffer(ctx, PIPE_SHADER_COMPUTE, 0, &saved_cb);
si_compute_internal_end(sctx);
}
void si_init_compute_blit_functions(struct si_context *sctx)
{
sctx->b.clear_buffer = si_pipe_clear_buffer;
}
+
+/* Clear a region of a color surface to a constant value. */
+void si_compute_clear_render_target(struct pipe_context *ctx,
+ struct pipe_surface *dstsurf,
+ const union pipe_color_union *color,
+ unsigned dstx, unsigned dsty,
+ unsigned width, unsigned height)
+{
+ struct si_context *sctx = (struct si_context *)ctx;
+ unsigned num_layers = dstsurf->u.tex.last_layer -
dstsurf->u.tex.first_layer + 1;
+ unsigned data[4 + sizeof(color->ui)] = {dstx, dsty,
dstsurf->u.tex.first_layer, 0};
+
+ if (width == 0 || height == 0)
+ return;
+
+ if (util_format_is_srgb(dstsurf->format)) {
+ union pipe_color_union color_srgb;
+ for (int i = 0; i < 3; i++)
+ color_srgb.f[i] =
util_format_linear_to_srgb_float(color->f[i]);
+ color_srgb.f[3] = color->f[3];
+ memcpy(data + 4, color_srgb.ui, sizeof(color->ui));
+ } else {
+ memcpy(data + 4, color->ui, sizeof(color->ui));
+ }
+
+ si_compute_internal_begin(sctx);
+ sctx->flags |= SI_CONTEXT_CS_PARTIAL_FLUSH |
+ si_get_flush_flags(sctx, SI_COHERENCY_SHADER, L2_STREAM);
+ si_make_CB_shader_coherent(sctx, dstsurf->texture->nr_samples, true);
+
+ struct pipe_constant_buffer saved
Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA
Sorry that I step in so late, but the whole family recover slowly from a bad flu... Tried your 'latest" three series altogether with my Polaris 20 (NIR!). UH and UV hang after some seconds reliable. VM faults. Have to dig deeper in (remote) to get some logs. But my reported Polaris triangle corruptions are solved, now. W'll try to verify which patches fixed it. Look here: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079319-running-the-radeonsi-nir-back-end-with-mesa-19-1-git?p=1079390#post1079390 Greetings, Dieter Am 07.02.2019 02:21, schrieb Marek Olšák: Hi, This patch series increases radeonsi performance in some cases. glxgears performance decreases slightly. Visible VRAM is usually congested due to CPU accesses, which cause buffers to be evicted from that part of VRAM. This removes the congestion for all data pushed into const_uploader. We have had many problems with const_uploader slowing stuff down due to visible VRAM congestion. The most recent one is this Starcraft 2 issue report on github: https://github.com/iXit/Mesa-3D/issues/333 Since const_uploader reuses buffers from the winsys buffer cache, the odds are that the reused buffers are already evicted, so the first use is usually slower due to higher shader load latencies. This series uses SDMA to get constants into VRAM, so it doesn't have any of the above drawbacks. SC2 numbers with various other methods (from the github issue report): - originally: 50-55 fps - changing const_uploader to STREAM: 75-80 fps - use stream_uploader for constants in Nine: 90 fps - this series: 105-110 fps Trivial benchmarks such as glxgears can expect 20% decrease in performance due to the added cost of the SDMA CS ioctl that wasn't there before. CPU-bound apps with many IBs are almost unaffected thanks to winsys multithreading. Feedback welcome, Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] radeonsi: NIR - Polaris triangle sprinkling running UH SOLVED - finally
Hello Marek, Timo, Nicolai, Timo SOLVED this long-standing NIR corruption on Polaris with his 'nir: rewrite varying component packing' commit. It was triggered with commit 86b52d42368ac496fe24bc6674e754c323381635 Author: Marek Olšák Date: Fri Jul 13 00:23:36 2018 -0400 radeonsi: reduce LDS stalls by 40% for tessellation 40% is the decrease in the LGKM counter (which includes SMEM too) for the GFX9 LSHS stage. This will make the LDS size slightly larger, but I wasn't able to increase the patch stride without corruption, so I'm increasing the vertex stride. and now finally SOLVED with commit 26aa460940f6222565ad5eb40a21c2377c59c3a6 Author: Timothy Arceri Date: Mon Dec 10 10:23:51 2018 +1100 nir: rewrite varying component packing There are a number of reasons for the rewrite. 1. Adding support for packing tess patch varyings in a sane way. 2. Making use of qsort allowing the code to be much easier to follow. 3. Fixes a bug where different interp types caused component packing to be skipped for all varyings in some scenarios. 4. Allows us to add a crude live range analysis for deciding which components should be packed together. This support can optionally be added in a future patch. Reviewed-by: Jason Ekstrand Maybe it should backported (Cc: ) ) for 19.0? I hope my bisect help to bring some more understanding for this Polaris NIR bug. Now, hunting for the (last) 19.0+ EQAA regression (DiRT Rally, black squares like radv/DXVK corruption, NOT NIR related) and 'meson' OpenCL (Clover) build error. Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute
GREAT stuff, Marek! But sadly some crashes. Is my LLVM git version to old? 7. Jan 2019 (short before 8.0 cut) LLVM (http://llvm.org/): LLVM version 8.0.0svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: nehalem Registered Targets: amdgcn - AMD GCN GPUs r600 - AMD GPUs HD2XXX-HD6XXX x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 Please have a look at my post @Phoronix: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984 Thanks, Dieter Am 13.02.2019 06:15, schrieb Marek Olšák: Hi, This patch series uses async compute to do primitive culling before the vertex shader. It significantly improves performance for applications that use a lot of geometry that is invisible because primitives don't intersect sample points or there are a lot of back faces, etc. It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100% stable. It supports all chips all the way from Sea Islands to Radeon VII. As you can see in the results marked (ENABLED) in the picture below, it destroys our competition (The GeForce results are from a Phoronix article from 2017, the latest ones I could find): Benchmark: ParaView - Many Spheres - 2560x1440 https://people.freedesktop.org/~mareko/prim-discard-cs-results.png The last patch describes the implementation and functional limitations if you can find the huge code comment, so I'm not gonna do that here. I decided to enable this optimization on all Pro graphics cards. The reason is that I haven't had time to benchmark games. This decision may be changed based on community feedback, etc. People using the Pro graphics cards can disable this by setting AMD_DEBUG=nopd, and people using consumer graphics cards can enable this by setting AMD_DEBUG=pd. So you always have a choice. Eventually we might also enable this on consumer graphics cards for those games that benefit. It might decrease performance if there is not enough invisible geometry. Branch: https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs Please review. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute
Now with LLVM 9.0 git;-) Running, except mplayer/mpv (same as before). mplayer: ../src/gallium/drivers/radeon/radeon_winsys.h:866: radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' failed. Abbruch (core dumped) mpv: ../src/gallium/drivers/radeon/radeon_winsys.h:866: radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' failed. Abbruch (core dumped) And this after glxgears, Blender, FreeCAD, UH and UV: [38939.440950] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 679c61fd is still alive [38939.440993] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 679c61fd is still alive [38964.901076] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 9c4b659b is still alive [38964.901130] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 9c4b659b is still alive [38980.844577] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 1bee3a35 is still alive [38980.844642] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 1bee3a35 is still alive Newer 'amd-staging-drm-next' needed? #0bf64b0a9f78 currently If I only had some big triangle apps...;-) Dieter Am 13.02.2019 17:36, schrieb Marek Olšák: Dieter, you need final LLVM 8.0. Marek On Wed, Feb 13, 2019 at 11:02 AM Dieter Nützel wrote: GREAT stuff, Marek! But sadly some crashes. Is my LLVM git version to old? 7. Jan 2019 (short before 8.0 cut) LLVM (http://llvm.org/): LLVM version 8.0.0svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: nehalem Registered Targets: amdgcn - AMD GCN GPUs r600 - AMD GPUs HD2XXX-HD6XXX x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 Please have a look at my post @Phoronix: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984 Thanks, Dieter Am 13.02.2019 06:15, schrieb Marek Olšák: Hi, This patch series uses async compute to do primitive culling before the vertex shader. It significantly improves performance for applications that use a lot of geometry that is invisible because primitives don't intersect sample points or there are a lot of back faces, etc. It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100% stable. It supports all chips all the way from Sea Islands to Radeon VII. As you can see in the results marked (ENABLED) in the picture below, it destroys our competition (The GeForce results are from a Phoronix article from 2017, the latest ones I could find): Benchmark: ParaView - Many Spheres - 2560x1440 https://people.freedesktop.org/~mareko/prim-discard-cs-results.png The last patch describes the implementation and functional limitations if you can find the huge code comment, so I'm not gonna do that here. I decided to enable this optimization on all Pro graphics cards. The reason is that I haven't had time to benchmark games. This decision may be changed based on community feedback, etc. People using the Pro graphics cards can disable this by setting AMD_DEBUG=nopd, and people using consumer graphics cards can enable this by setting AMD_DEBUG=pd. So you always have a choice. Eventually we might also enable this on consumer graphics cards for those games that benefit. It might decrease performance if there is not enough invisible geometry. Branch: https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs Please review. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi/nir: set shader_buffers_declared properly
Tested-by: Dieter Nützel
Am 12.02.2019 04:46, schrieb Timothy Arceri:
---
src/gallium/drivers/radeonsi/si_shader_nir.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 55a950a675c..c547f5f1c30 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -687,10 +687,15 @@ void si_nir_scan_shader(const struct nir_shader
*nir,
struct set *ubo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
_mesa_key_pointer_equal);
+ struct set *ssbo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
+ _mesa_key_pointer_equal);
/* Intialise const_file_max[0] */
info->const_file_max[0] = -1;
+ /* The first 8 are reserved for atomic counters using ssbo */
+ unsigned ssbo_idx = 8;
+
unsigned ubo_idx = 1;
nir_foreach_variable(variable, &nir->uniforms) {
const struct glsl_type *type = variable->type;
@@ -705,12 +710,16 @@ void si_nir_scan_shader(const struct nir_shader
*nir,
*/
if (variable->interface_type != NULL) {
if (variable->data.mode == nir_var_uniform ||
- variable->data.mode == nir_var_mem_ubo) {
+ variable->data.mode == nir_var_mem_ubo ||
+ variable->data.mode == nir_var_mem_ssbo) {
+
+ struct set *buf_set = variable->data.mode ==
nir_var_mem_ssbo ?
+ ssbo_set : ubo_set;
unsigned block_count;
if (base_type != GLSL_TYPE_INTERFACE) {
struct set_entry *entry =
- _mesa_set_search(ubo_set,
variable->interface_type);
+ _mesa_set_search(buf_set,
variable->interface_type);
/* Check if we have already processed
* a member from this ubo.
@@ -723,16 +732,18 @@ void si_nir_scan_shader(const struct nir_shader
*nir,
block_count = aoa_size;
}
-info->const_buffers_declared |= u_bit_consecutive(ubo_idx,
block_count);
- ubo_idx += block_count;
+ if (variable->data.mode == nir_var_uniform ||
+ variable->data.mode == nir_var_mem_ubo) {
+ info->const_buffers_declared |= u_bit_consecutive(ubo_idx,
block_count);
+ ubo_idx += block_count;
+ } else {
+ assert(variable->data.mode ==
nir_var_mem_ssbo);
- _mesa_set_add(ubo_set,
variable->interface_type);
- }
+ info->shader_buffers_declared |= u_bit_consecutive(ssbo_idx,
block_count);
+ ssbo_idx += block_count;
+ }
- if (variable->data.mode == nir_var_mem_ssbo) {
- /* TODO: make this more accurate */
- info->shader_buffers_declared =
- u_bit_consecutive(0,
SI_NUM_SHADER_BUFFERS);
+ _mesa_set_add(buf_set,
variable->interface_type);
}
continue;
@@ -776,6 +787,7 @@ void si_nir_scan_shader(const struct nir_shader
*nir,
}
_mesa_set_destroy(ubo_set, NULL);
+ _mesa_set_destroy(ssbo_set, NULL);
info->num_written_clipdistance = nir->info.clip_distance_array_size;
info->num_written_culldistance = nir->info.cull_distance_array_size;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] radeonsi/nir: set colors_read properly
For the series
Tested-by: Dieter Nützel
on Polaris 20
Dieter
Am 12.02.2019 01:15, schrieb Timothy Arceri:
shader-db results for VEGA64:
Totals from affected shaders:
SGPRS: 1976 -> 1976 (0.00 %)
VGPRS: 1240 -> 1144 (-7.74 %)
Spilled SGPRs: 145 -> 145 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 34632 -> 34604 (-0.08 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 261 -> 285 (9.20 %)
Wait states: 0 -> 0 (0.00 %)
---
src/gallium/drivers/radeonsi/si_shader_nir.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 4eec57b406d..55a950a675c 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -74,9 +74,18 @@ static void gather_intrinsic_load_deref_info(const
nir_shader *nir,
}
break;
}
- default:
+ default: {
+ unsigned semantic_name, semantic_index;
+ tgsi_get_gl_varying_semantic(var->data.location, true,
+&semantic_name, &semantic_index);
+
+ if (semantic_name == TGSI_SEMANTIC_COLOR) {
+ uint8_t mask =
nir_ssa_def_components_read(&instr->dest.ssa);
+ info->colors_read |= mask << (semantic_index * 4);
+ }
break;
}
+ }
}
static void scan_instruction(const struct nir_shader *nir,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute
Got it (merged in), thanks. But now I need some sleep. Have to drive my wife to the hospital in a few hours. No, not hyperacute. Dieter Am 14.02.2019 03:07, schrieb Marek Olšák: I just updated the branch, fixing video players. Marek On Wed, Feb 13, 2019 at 8:28 PM Dieter Nützel wrote: Now with LLVM 9.0 git;-) Running, except mplayer/mpv (same as before). mplayer: ../src/gallium/drivers/radeon/radeon_winsys.h:866: radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' failed. Abbruch (core dumped) mpv: ../src/gallium/drivers/radeon/radeon_winsys.h:866: radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' failed. Abbruch (core dumped) And this after glxgears, Blender, FreeCAD, UH and UV: [38939.440950] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 679c61fd is still alive [38939.440993] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 679c61fd is still alive [38964.901076] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 9c4b659b is still alive [38964.901130] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 9c4b659b is still alive [38980.844577] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 1bee3a35 is still alive [38980.844642] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 1bee3a35 is still alive Newer 'amd-staging-drm-next' needed? #0bf64b0a9f78 currently If I only had some big triangle apps...;-) Dieter Am 13.02.2019 17:36, schrieb Marek Olšák: Dieter, you need final LLVM 8.0. Marek On Wed, Feb 13, 2019 at 11:02 AM Dieter Nützel wrote: GREAT stuff, Marek! But sadly some crashes. Is my LLVM git version to old? 7. Jan 2019 (short before 8.0 cut) LLVM (http://llvm.org/): LLVM version 8.0.0svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: nehalem Registered Targets: amdgcn - AMD GCN GPUs r600 - AMD GPUs HD2XXX-HD6XXX x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 Please have a look at my post @Phoronix: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984 Thanks, Dieter Am 13.02.2019 06:15, schrieb Marek Olšák: Hi, This patch series uses async compute to do primitive culling before the vertex shader. It significantly improves performance for applications that use a lot of geometry that is invisible because primitives don't intersect sample points or there are a lot of back faces, etc. It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100% stable. It supports all chips all the way from Sea Islands to Radeon VII. As you can see in the results marked (ENABLED) in the picture below, it destroys our competition (The GeForce results are from a Phoronix article from 2017, the latest ones I could find): Benchmark: ParaView - Many Spheres - 2560x1440 https://people.freedesktop.org/~mareko/prim-discard-cs-results.png The last patch describes the implementation and functional limitations if you can find the huge code comment, so I'm not gonna do that here. I decided to enable this optimization on all Pro graphics cards. The reason is that I haven't had time to benchmark games. This decision may be changed based on community feedback, etc. People using the Pro graphics cards can disable this by setting AMD_DEBUG=nopd, and people using consumer graphics cards can enable this by setting AMD_DEBUG=pd. So you always have a choice. Eventually we might also enable this on consumer graphics cards for those games that benefit. It might decrease performance if there is not enough invisible geometry. Branch: https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs Please review. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute
For the whole series (the updated branch merged in) Tested-by: Dieter Nützel on Polaris 20 FreeCAD, Blender, UH, UV, US, some VTK apps No surprising speed up but e.g. NO slowdown. tb stands even for [Mesa-dev] [PATCH 0/4] RadeonSI: Follow-up for the primitive culling series too (but no SI, here). mplayer / mpv works like a charm, again. ParaView-5.6.0-MPI-Linux-64bit 1920x1080 pd off ~18 fps pd on ~24 fps ! ;-) 2560x1440 pd off ~14 fps pd on ~16 fps ./pvbatch ../lib/python2.7/site-packages/paraview/benchmark/manyspheres.py -s 100 -r 726 -v 1920,1080 -f 30 Is this right? Poor Intel Xeon X3470, 2.93 GHz, 3.2 GHz turbo, 4c/8t 24 GB Polaris 20, 8 GB PCIe 2.1 only (NO PCIe atomics) Dieter Am 14.02.2019 03:07, schrieb Marek Olšák: I just updated the branch, fixing video players. Marek On Wed, Feb 13, 2019 at 8:28 PM Dieter Nützel wrote: Now with LLVM 9.0 git;-) Running, except mplayer/mpv (same as before). mplayer: ../src/gallium/drivers/radeon/radeon_winsys.h:866: radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' failed. Abbruch (core dumped) mpv: ../src/gallium/drivers/radeon/radeon_winsys.h:866: radeon_get_heap_index: Assertion `!"32BIT without WC is disallowed"' failed. Abbruch (core dumped) And this after glxgears, Blender, FreeCAD, UH and UV: [38939.440950] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 679c61fd is still alive [38939.440993] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 679c61fd is still alive [38964.901076] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 9c4b659b is still alive [38964.901130] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 9c4b659b is still alive [38980.844577] [drm:amdgpu_ctx_mgr_entity_fini [amdgpu]] *ERROR* ctx 1bee3a35 is still alive [38980.844642] [drm:amdgpu_ctx_mgr_fini [amdgpu]] *ERROR* ctx 1bee3a35 is still alive Newer 'amd-staging-drm-next' needed? #0bf64b0a9f78 currently If I only had some big triangle apps...;-) Dieter Am 13.02.2019 17:36, schrieb Marek Olšák: Dieter, you need final LLVM 8.0. Marek On Wed, Feb 13, 2019 at 11:02 AM Dieter Nützel wrote: GREAT stuff, Marek! But sadly some crashes. Is my LLVM git version to old? 7. Jan 2019 (short before 8.0 cut) LLVM (http://llvm.org/): LLVM version 8.0.0svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: nehalem Registered Targets: amdgcn - AMD GCN GPUs r600 - AMD GPUs HD2XXX-HD6XXX x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 Please have a look at my post @Phoronix: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079916-radeonsi-picks-up-primitive-culling-with-async-compute-for-performance-wins?p=1079984#post1079984 Thanks, Dieter Am 13.02.2019 06:15, schrieb Marek Olšák: Hi, This patch series uses async compute to do primitive culling before the vertex shader. It significantly improves performance for applications that use a lot of geometry that is invisible because primitives don't intersect sample points or there are a lot of back faces, etc. It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100% stable. It supports all chips all the way from Sea Islands to Radeon VII. As you can see in the results marked (ENABLED) in the picture below, it destroys our competition (The GeForce results are from a Phoronix article from 2017, the latest ones I could find): Benchmark: ParaView - Many Spheres - 2560x1440 https://people.freedesktop.org/~mareko/prim-discard-cs-results.png The last patch describes the implementation and functional limitations if you can find the huge code comment, so I'm not gonna do that here. I decided to enable this optimization on all Pro graphics cards. The reason is that I haven't had time to benchmark games. This decision may be changed based on community feedback, etc. People using the Pro graphics cards can disable this by setting AMD_DEBUG=nopd, and people using consumer graphics cards can enable this by setting AMD_DEBUG=pd. So you always have a choice. Eventually we might also enable this on consumer graphics cards for those games that benefit. It might decrease performance if there is not enough invisible geometry. Branch: https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs Please review. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: remove simple dead if detection from nir_opt_dead_cf()
Tested-by: Dieter Nützel
running together with
[Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute
- V2
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215240.html
Dieter
Am 14.02.2019 02:37, schrieb Timothy Arceri:
This was probably useful when it was first written, however it
looks to be no longer necessary.
As far as I can tell these days dce is smart enough to remove useless
instructions from if branches. Once this is done
nir_opt_peephole_select() will end up removing the empty if.
Removing this support reduces the dolphin uber shader compilation
time by around 60%. Compile time is reduced due to no longer having
to compute the live ssa defs metadata so much.
No shader-db changes on i965 or radeonsi.
---
src/compiler/nir/nir_opt_dead_cf.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/compiler/nir/nir_opt_dead_cf.c
b/src/compiler/nir/nir_opt_dead_cf.c
index 14986732096..053c5743527 100644
--- a/src/compiler/nir/nir_opt_dead_cf.c
+++ b/src/compiler/nir/nir_opt_dead_cf.c
@@ -180,7 +180,7 @@ def_not_live_out(nir_ssa_def *def, void *state)
}
/*
- * Test if a loop node or if node is dead. Such nodes are dead if:
+ * Test if a loop node is dead. Such nodes are dead if:
*
* 1) It has no side effects (i.e. intrinsics which could possibly
affect the
* state of the program aside from producing an SSA value, indicated
by a lack
@@ -198,7 +198,7 @@ def_not_live_out(nir_ssa_def *def, void *state)
static bool
node_is_dead(nir_cf_node *node)
{
- assert(node->type == nir_cf_node_loop || node->type ==
nir_cf_node_if);
+ assert(node->type == nir_cf_node_loop);
nir_block *before = nir_cf_node_as_block(nir_cf_node_prev(node));
nir_block *after = nir_cf_node_as_block(nir_cf_node_next(node));
@@ -230,11 +230,6 @@ dead_cf_block(nir_block *block)
{
nir_if *following_if = nir_block_get_following_if(block);
if (following_if) {
- if (node_is_dead(&following_if->cf_node)) {
- nir_cf_node_remove(&following_if->cf_node);
- return true;
- }
-
if (!nir_src_is_const(following_if->condition))
return false;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA
Am 12.02.2019 05:10, schrieb Dieter Nützel: Am 12.02.2019 03:22, schrieb Dieter Nützel: Am 12.02.2019 00:40, schrieb Dieter Nützel: Sorry that I step in so late, but the whole family recover slowly from a bad flu... Tried your 'latest" three series altogether with my Polaris 20 (NIR!). UH and UV hang after some seconds reliable. VM faults. Have to dig deeper in (remote) to get some logs. UH [47001.185090] amdgpu :01:00.0: GPU fault detected: 147 0x0b384801 for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586 [47001.185094] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0373EF67 [47001.185096] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001 [47001.185098] amdgpu :01:00.0: VM fault (0x01, vmid 3, pasid 32786) at page 57929575, read from 'TC4' (0x54433400) (72) [47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=11380701, emitted seq=11380703 [47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 [47011.401787] amdgpu :01:00.0: GPU reset begin! [47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:49:crtc-0] hw_done or flip_done timed out These GPU faults are SOLVED after reverting the SDMA (1-4) series. So I gave this a second change with LLVM 9.0 git. + some other patches e83af67eed7 (HEAD -> master) ac: use new LLVM 8 intrinsic when loading 16-bit values 7f32d569ffc ac: add ac_build_llvm8_tbuffer_load() helper 037bda54a7d nir: remove simple dead if detection from nir_opt_dead_cf() 51fe88ff1ab radeonsi/nir: set shader_buffers_declared properly e66a73aa1a6 radeonsi/nir: set colors_read properly 83955dfc81a radeonsi/nir: set input_usage_mask properly 4c355a562db radeonsi: use SDMA for uploading data through const_uploader 6855f871e47 gallium/u_upload_mgr: allow use of FLUSH_EXPLICIT with persistent mappings 2116355fc01 gallium/u_threaded: always unmap const_uploader 6e70cce39f3 st/mesa: always unmap the uploader in st_atom_array.c 22a88ca1d92 radeonsi: re-initialize query buffers if they are reused 6775665e5ee (origin/master, origin/HEAD) spirv: Eliminate dead input/output variables after translation. UH run some sences but (same? - Yes.) GPU fault. - Shit, sadly overwritten my dmesg.log. :-( UV run some sences but (same? - Yes.) GPU fault. Unigine Valley Benchmark 1.0 (1.0)Unigine~# world_load valley/valley Loading "valley/valley.cpp" 126ms Loading "valley/valley.mat" 72 materials 1160ms Loading "valley/sound/sound.prop" 142 properties 1ms Loading "valley/valley.world" 2253ms valley_x64: ../src/gallium/auxiliary/util/u_inlines.h:81: pipe_reference_described: Assertion `count != 1' failed. [ 1079.415836] amdgpu :01:00.0: GPU fault detected: 147 0x0ca04801 for process valley_x64 pid 18050 thread valley_x64:cs0 pid 18071 [ 1079.415841] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x094A9594 [ 1079.415842] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x08048001 [ 1079.415845] amdgpu :01:00.0: VM fault (0x01, vmid 4, pasid 32769) at page 155882900, read from 'TC4' (0x54433400) (72) [ 1089.543336] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=91489, emitted seq=91491 [ 1089.543379] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process valley_x64 pid 18050 thread valley_x64:cs0 pid 18071 [ 1089.543382] amdgpu :01:00.0: GPU reset begin! [ 1099.773342] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:49:crtc-0] hw_done or flip_done timed out Hope that helps some. Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] radeonsi: NIR - Polaris triangle sprinkling running UH SOLVED - finally
Am 16.02.2019 03:56, schrieb Timothy Arceri: On 13/2/19 8:28 am, Dieter Nützel wrote: Hello Marek, Timo, Nicolai, Timo SOLVED this long-standing NIR corruption on Polaris with his 'nir: rewrite varying component packing' commit. It was triggered with commit 86b52d42368ac496fe24bc6674e754c323381635 Author: Marek Olšák Date: Fri Jul 13 00:23:36 2018 -0400 radeonsi: reduce LDS stalls by 40% for tessellation 40% is the decrease in the LGKM counter (which includes SMEM too) for the GFX9 LSHS stage. This will make the LDS size slightly larger, but I wasn't able to increase the patch stride without corruption, so I'm increasing the vertex stride. and now finally SOLVED with commit 26aa460940f6222565ad5eb40a21c2377c59c3a6 Author: Timothy Arceri Date: Mon Dec 10 10:23:51 2018 +1100 nir: rewrite varying component packing There are a number of reasons for the rewrite. 1. Adding support for packing tess patch varyings in a sane way. 2. Making use of qsort allowing the code to be much easier to follow. 3. Fixes a bug where different interp types caused component packing to be skipped for all varyings in some scenarios. 4. Allows us to add a crude live range analysis for deciding which components should be packed together. This support can optionally be added in a future patch. Reviewed-by: Jason Ekstrand Maybe it should backported (Cc: lists.freedesktop.org>) ) for 19.0? I'd rather it didn't since NIR isn't default for radeonsi and this is use for other drivers like RADV. I'd rather have more testing in the dev branch. Of course, your're right. - Running NIR to long...;-) Dieter BTW 'New' stuttering (shader compiler) with Rocket League went in. Our son is unhappy. Have to dig (bisect). This change really shouldn't fix anything, it could just be that the change avoids the bug. I'm really not sure. One thing this change did fix was a bug with doubles, but I wasn't aware of anything actually using doubles so I doubt this is it. I hope my bisect help to bring some more understanding for this Polaris NIR bug. Now, hunting for the (last) 19.0+ EQAA regression (DiRT Rally, black squares like radv/DXVK corruption, NOT NIR related) and 'meson' OpenCL (Clover) build error. Greetings, Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] radeonsi: use SDMA for uploading data through const_uploader
For the _rev2_ version (Patchwork Mesa) series is
Tested-by: Dieter Nützel
on Polaris 20
UH+UV working flawlessly, now.
No 'measurable' speed decrease. - GREAT!
Blender, FreeCAD, glmark2 all fine.
But I had to have rebased part 4 (see attachment).
Dieter
Am 07.02.2019 02:22, schrieb Marek Olšák:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_buffer.c | 56 ++--
src/gallium/drivers/radeonsi/si_dma_cs.c | 19
src/gallium/drivers/radeonsi/si_gfx_cs.c | 42 +++---
src/gallium/drivers/radeonsi/si_pipe.c | 23 ++
src/gallium/drivers/radeonsi/si_pipe.h | 17 +++
5 files changed, 131 insertions(+), 26 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_buffer.c
b/src/gallium/drivers/radeonsi/si_buffer.c
index c01118ce96a..3f8db7cf4f0 100644
--- a/src/gallium/drivers/radeonsi/si_buffer.c
+++ b/src/gallium/drivers/radeonsi/si_buffer.c
@@ -433,21 +433,29 @@ static void *si_buffer_transfer_map(struct
pipe_context *ctx,
if (si_invalidate_buffer(sctx, buf)) {
/* At this point, the buffer is always idle. */
usage |= PIPE_TRANSFER_UNSYNCHRONIZED;
} else {
/* Fall back to a temporary buffer. */
usage |= PIPE_TRANSFER_DISCARD_RANGE;
}
}
- if ((usage & PIPE_TRANSFER_DISCARD_RANGE) &&
+ if (usage & PIPE_TRANSFER_FLUSH_EXPLICIT &&
+ buf->b.b.flags & SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA)
{
+ usage &= ~(PIPE_TRANSFER_UNSYNCHRONIZED |
+ PIPE_TRANSFER_PERSISTENT);
+ usage |= PIPE_TRANSFER_DISCARD_RANGE;
+ force_discard_range = true;
+ }
+
+ if (usage & PIPE_TRANSFER_DISCARD_RANGE &&
((!(usage & (PIPE_TRANSFER_UNSYNCHRONIZED |
PIPE_TRANSFER_PERSISTENT))) ||
(buf->flags & RADEON_FLAG_SPARSE))) {
assert(usage & PIPE_TRANSFER_WRITE);
/* Check if mapping this buffer would cause waiting for the GPU.
*/
if (buf->flags & RADEON_FLAG_SPARSE ||
force_discard_range ||
si_rings_is_buffer_referenced(sctx, buf->buf,
RADEON_USAGE_READWRITE) ||
@@ -514,32 +522,72 @@ static void *si_buffer_transfer_map(struct
pipe_context *ctx,
data += box->x;
return si_buffer_get_transfer(ctx, resource, usage, box,
ptransfer, data, NULL, 0);
}
static void si_buffer_do_flush_region(struct pipe_context *ctx,
struct pipe_transfer *transfer,
const struct pipe_box *box)
{
+ struct si_context *sctx = (struct si_context*)ctx;
struct si_transfer *stransfer = (struct si_transfer*)transfer;
struct si_resource *buf = si_resource(transfer->resource);
if (stransfer->staging) {
unsigned src_offset = stransfer->offset +
transfer->box.x % SI_MAP_BUFFER_ALIGNMENT
+
(box->x - transfer->box.x);
+ if (buf->b.b.flags &
SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA) {
+ /* This should be true for all uploaders. */
+ assert(transfer->box.x == 0);
+
+ /* Find a previous upload and extend its range. The last
+* upload is likely to be at the end of the list.
+*/
+ for (int i = sctx->num_sdma_uploads - 1; i >= 0; i--) {
+ struct si_sdma_upload *up =
&sctx->sdma_uploads[i];
+
+ if (up->dst != buf)
+ continue;
+
+ assert(up->src == stransfer->staging);
+ assert(box->x > up->dst_offset);
+ up->size = box->x + box->width - up->dst_offset;
+ return;
+ }
+
+ /* Enlarge the array if it's full. */
+ if (sctx->num_sdma_uploads == sctx->max_sdma_uploads) {
+ unsigned size;
+
+ sctx->max_sdma_uploads += 4;
+ size = sctx->max_sdma_uploads *
sizeof(sctx->sdma_uploads[0]);
+ sctx->sdma_uploads =
realloc(sctx->sdma_uploads, size);
+ }
+
+ /* Add a new upload. */
+ struct si_sdma_upload *up =
+ &sctx->sdma_uploads[sctx->num_sdma_upload
Re: [Mesa-dev] [PATCH 7/7] radeonsi: implement ARB/KHR_parallel_shader_compile callbacks
For the series
Tested-by: Dieter Nützel
Do we have a (special) test in the wild?
Dieter
Am 25.02.2019 19:27, schrieb Marek Olšák:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index b965d9d64d4..7dbd4cb2c40 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -19,20 +19,21 @@
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT
SHALL
* THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
* DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
OR
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include "si_pipe.h"
#include "si_public.h"
#include "si_shader_internal.h"
+#include "si_compute.h"
#include "sid.h"
#include "ac_llvm_util.h"
#include "radeon/radeon_uvd.h"
#include "gallivm/lp_bld_misc.h"
#include "util/disk_cache.h"
#include "util/u_log.h"
#include "util/u_memory.h"
#include "util/u_suballoc.h"
#include "util/u_tests.h"
@@ -826,20 +827,46 @@ static void si_disk_cache_create(struct
si_screen *sscreen)
*/
STATIC_ASSERT(ALL_FLAGS <= UINT_MAX);
shader_debug_flags |= (uint64_t)sscreen->info.address32_hi << 32;
sscreen->disk_shader_cache =
disk_cache_create(sscreen->info.name,
cache_id,
shader_debug_flags);
}
+static void si_set_max_shader_compiler_threads(struct pipe_screen
*screen,
+ unsigned max_threads)
+{
+ struct si_screen *sscreen = (struct si_screen *)screen;
+
+ /* This function doesn't allow a greater number of threads than
+* the queue had at its creation. */
+ util_queue_adjust_num_threads(&sscreen->shader_compiler_queue,
+ max_threads);
+ /* Don't change the number of threads on the low priority queue. */
+}
+
+static bool si_is_parallel_shader_compilation_finished(struct
pipe_screen *screen,
+ void *shader,
+ unsigned shader_type)
+{
+ if (shader_type == PIPE_SHADER_COMPUTE) {
+ struct si_compute *cs = (struct si_compute*)shader;
+
+ return util_queue_fence_is_signalled(&cs->ready);
+ }
+ struct si_shader_selector *sel = (struct si_shader_selector *)shader;
+
+ return util_queue_fence_is_signalled(&sel->ready);
+}
+
struct pipe_screen *radeonsi_screen_create(struct radeon_winsys *ws,
const struct pipe_screen_config
*config)
{
struct si_screen *sscreen = CALLOC_STRUCT(si_screen);
unsigned hw_threads, num_comp_hi_threads, num_comp_lo_threads, i;
if (!sscreen) {
return NULL;
}
@@ -856,20 +883,24 @@ struct pipe_screen
*radeonsi_screen_create(struct radeon_winsys *ws,
}
sscreen->debug_flags = debug_get_flags_option("R600_DEBUG",
debug_options, 0);
sscreen->debug_flags |= debug_get_flags_option("AMD_DEBUG",
debug_options, 0);
/* Set functions first. */
sscreen->b.context_create = si_pipe_create_context;
sscreen->b.destroy = si_destroy_screen;
+ sscreen->b.set_max_shader_compiler_threads =
+ si_set_max_shader_compiler_threads;
+ sscreen->b.is_parallel_shader_compilation_finished =
+ si_is_parallel_shader_compilation_finished;
si_init_screen_get_functions(sscreen);
si_init_screen_buffer_functions(sscreen);
si_init_screen_fence_functions(sscreen);
si_init_screen_state_functions(sscreen);
si_init_screen_texture_functions(sscreen);
si_init_screen_query_functions(sscreen);
/* Set these flags in debug_flags early, so that the shader cache
takes
* them into account.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute
Hello Marek, do you plan to commit or rebase both set? Dieter Am 14.02.2019 07:29, schrieb Marek Olšák: I have some fixes for Sea Islands that improve Radeon 290X performance to 43 fps, moving it just below Radeon VII in the picture. Marek On Wed, Feb 13, 2019 at 12:16 AM Marek Olšák wrote: Hi, This patch series uses async compute to do primitive culling before the vertex shader. It significantly improves performance for applications that use a lot of geometry that is invisible because primitives don't intersect sample points or there are a lot of back faces, etc. It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100% stable. It supports all chips all the way from Sea Islands to Radeon VII. As you can see in the results marked (ENABLED) in the picture below, it destroys our competition (The GeForce results are from a Phoronix article from 2017, the latest ones I could find): Benchmark: ParaView - Many Spheres - 2560x1440 https://people.freedesktop.org/~mareko/prim-discard-cs-results.png The last patch describes the implementation and functional limitations if you can find the huge code comment, so I'm not gonna do that here. I decided to enable this optimization on all Pro graphics cards. The reason is that I haven't had time to benchmark games. This decision may be changed based on community feedback, etc. People using the Pro graphics cards can disable this by setting AMD_DEBUG=nopd, and people using consumer graphics cards can enable this by setting AMD_DEBUG=pd. So you always have a choice. Eventually we might also enable this on consumer graphics cards for those games that benefit. It might decrease performance if there is not enough invisible geometry. Branch: https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs Please review. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)
Hello Marek,
this series need a rebase (if you have some time).
Dieter
Am 12.02.2019 19:12, schrieb Marek Olšák:
From: Marek Olšák
initialize all non-compute context functions to NULL.
v2: fix SI
---
src/gallium/drivers/radeonsi/si_blit.c| 14 ++-
src/gallium/drivers/radeonsi/si_clear.c | 7 +-
src/gallium/drivers/radeonsi/si_compute.c | 15 +--
src/gallium/drivers/radeonsi/si_descriptors.c | 10 +-
src/gallium/drivers/radeonsi/si_gfx_cs.c | 29 +++---
src/gallium/drivers/radeonsi/si_pipe.c| 95 +++
src/gallium/drivers/radeonsi/si_pipe.h| 3 +-
src/gallium/drivers/radeonsi/si_state.c | 3 +-
src/gallium/drivers/radeonsi/si_state.h | 1 +
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
src/gallium/drivers/radeonsi/si_texture.c | 3 +
11 files changed, 130 insertions(+), 75 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index bb8d1cbd12d..f39cb5d143f 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -1345,25 +1345,31 @@ static void si_flush_resource(struct
pipe_context *ctx,
if (separate_dcc_dirty) {
tex->separate_dcc_dirty = false;
vi_separate_dcc_process_and_reset_stats(ctx, tex);
}
}
}
void si_decompress_dcc(struct si_context *sctx, struct si_texture
*tex)
{
- if (!tex->dcc_offset)
+ /* If graphics is disabled, we can't decompress DCC, but it shouldn't
+* be compressed either. The caller should simply discard it.
+*/
+ if (!tex->dcc_offset || !sctx->has_graphics)
return;
si_blit_decompress_color(sctx, tex, 0, tex->buffer.b.b.last_level,
0, util_max_layer(&tex->buffer.b.b, 0),
true);
}
void si_init_blit_functions(struct si_context *sctx)
{
sctx->b.resource_copy_region = si_resource_copy_region;
- sctx->b.blit = si_blit;
- sctx->b.flush_resource = si_flush_resource;
- sctx->b.generate_mipmap = si_generate_mipmap;
+
+ if (sctx->has_graphics) {
+ sctx->b.blit = si_blit;
+ sctx->b.flush_resource = si_flush_resource;
+ sctx->b.generate_mipmap = si_generate_mipmap;
+ }
}
diff --git a/src/gallium/drivers/radeonsi/si_clear.c
b/src/gallium/drivers/radeonsi/si_clear.c
index 9a00bb73b94..e1805f2a1c9 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -764,15 +764,18 @@ static void si_clear_texture(struct pipe_context
*pipe,
util_clear_render_target(pipe, sf, &color,
box->x, box->y,
box->width, box->height);
}
}
pipe_surface_reference(&sf, NULL);
}
void si_init_clear_functions(struct si_context *sctx)
{
- sctx->b.clear = si_clear;
sctx->b.clear_render_target = si_clear_render_target;
- sctx->b.clear_depth_stencil = si_clear_depth_stencil;
sctx->b.clear_texture = si_clear_texture;
+
+ if (sctx->has_graphics) {
+ sctx->b.clear = si_clear;
+ sctx->b.clear_depth_stencil = si_clear_depth_stencil;
+ }
}
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 1a62b3e0844..87addd53976 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -880,26 +880,28 @@ static void si_launch_grid(
info->block[0] * info->block[1] * info->block[2] > 256;
if (cs_regalloc_hang)
sctx->flags |= SI_CONTEXT_PS_PARTIAL_FLUSH |
SI_CONTEXT_CS_PARTIAL_FLUSH;
if (program->ir_type != PIPE_SHADER_IR_NATIVE &&
program->shader.compilation_failed)
return;
- if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
- si_update_fb_dirtiness_after_rendering(sctx);
- sctx->last_num_draw_calls = sctx->num_draw_calls;
- }
+ if (sctx->has_graphics) {
+ if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
+ si_update_fb_dirtiness_after_rendering(sctx);
+ sctx->last_num_draw_calls = sctx->num_draw_calls;
+ }
- si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+ si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
+ }
/* Add buffer sizes for memory checking in need_cs_space. */
si_context_add_resource_size(sctx, &program->shader.bo->b.b);
/* TODO: add the scratch buffer */
if (info->indirect) {
si_context_add_resource_size(sctx, info->indirect);
/* Indirect buffe
Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA
Hello Marek, you wrote with your series sent: [-] Trivial benchmarks such as glxgears can expect 20% decrease in performance due to the added cost of the SDMA CS ioctl that wasn't there before. [-] Any ideas to speed this up, again? glmark2 went from 9766 (best ever) down to 7455 (all with NIR). Or are micro benchmarks not worth more effort? Dieter SDMA === glmark2 2017.07 === OpenGL Information GL_VENDOR: X.Org GL_RENDERER: Radeon RX 580 Series (POLARIS10, DRM 3.30.0, 5.0.0-rc1-1.g7262353-default+, LLVM 9.0.0) GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.0-devel (git-a9b32aaa16) === [build] use-vbo=false: FPS: 3694 FrameTime: 0.271 ms [build] use-vbo=true: FPS: 9341 FrameTime: 0.107 ms [texture] texture-filter=nearest: FPS: 9140 FrameTime: 0.109 ms [texture] texture-filter=linear: FPS: 9163 FrameTime: 0.109 ms [texture] texture-filter=mipmap: FPS: 9161 FrameTime: 0.109 ms [shading] shading=gouraud: FPS: 9234 FrameTime: 0.108 ms [shading] shading=blinn-phong-inf: FPS: 9255 FrameTime: 0.108 ms [shading] shading=phong: FPS: 9226 FrameTime: 0.108 ms [shading] shading=cel: FPS: 9310 FrameTime: 0.107 ms [bump] bump-render=high-poly: FPS: 9298 FrameTime: 0.108 ms [bump] bump-render=normals: FPS: 9121 FrameTime: 0.110 ms [bump] bump-render=height: FPS: 9120 FrameTime: 0.110 ms libpng warning: iCCP: known incorrect sRGB profile [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 9858 FrameTime: 0.101 ms libpng warning: iCCP: known incorrect sRGB profile [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 9854 FrameTime: 0.101 ms [pulsar] light=false:quads=5:texture=false: FPS: 8468 FrameTime: 0.118 ms libpng warning: iCCP: known incorrect sRGB profile [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 5181 FrameTime: 0.193 ms libpng warning: iCCP: known incorrect sRGB profile [desktop] effect=shadow:windows=4: FPS: 5374 FrameTime: 0.186 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 824 FrameTime: 1.214 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 1114 FrameTime: 0.898 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 899 FrameTime: 1.112 ms [ideas] speed=duration: FPS: 3485 FrameTime: 0.287 ms [jellyfish] : FPS: 7992 FrameTime: 0.125 ms [terrain] : FPS: 1796 FrameTime: 0.557 ms [shadow] : FPS: 7350 FrameTime: 0.136 ms [refract] : FPS: 3595 FrameTime: 0.278 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 9401 FrameTime: 0.106 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 9413 FrameTime: 0.106 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 9417 FrameTime: 0.106 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 9365 FrameTime: 0.107 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 9451 FrameTime: 0.106 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 9300 FrameTime: 0.108 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 9440 FrameTime: 0.106 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 9392 FrameTime: 0.106 ms === glmark2 Score: 7455 === Before === glmark2 2017.07 === OpenGL Information GL_VENDOR: X.Org GL_RENDERER: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.20.0-rc3-1.g7262353-default+, LLVM 8.0.0) GL_VERSION:4.5 (Compatibility Profile) Mesa 19.0.0-devel (git-c49b3df3cb) === [build] use-vbo=false: FPS: 3373 FrameTime: 0.296 ms [build] use-vbo=true: FPS: 13121 FrameTime: 0.076 ms [texture] texture-filter=nearest: FPS: 12172 FrameTime: 0.082 ms [texture] texture-filter=linear: FPS: 12557 FrameTime: 0.080 ms [texture] texture-filter=mipmap: FPS: 12228 FrameTime: 0.082 ms [shading] shading=gouraud: FPS: 12536 FrameTime: 0.080 ms [shading] shading=blinn-phong-inf: FPS: 12782 FrameTime: 0.078 ms [shading] shading=phong: FPS: 12619 FrameTime: 0.079 ms [shading] shading=cel: FPS: 12735 FrameTime: 0.079 ms [bump] bump-render=high-poly: FPS: 11412 FrameTime: 0.088 ms [bump] bump-render=normals: FPS: 12467 FrameTime: 0.080 ms [bump] bump-render=height: FPS: 12422 FrameTime: 0.081 ms libpng warning: iCCP: known incorrect sRGB profile [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 13252 FrameTime: 0.075 ms libpng warning: iCCP: known incorrect sRGB profile [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 11468 FrameTime: 0.087 ms [pulsar] light=false:quads=5:texture=
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
This commit (#317f10bf404) brake whole tessellation (empty parts of the screen) running UH under radeonsi NIR on Polaris 20 (RX580). 317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit commit 317f10bf404b562e1dda79c0636aee86beeccc2f Author: Timur Kristóf Date: Tue Feb 5 18:08:24 2019 +0100 nir: Add ability for shaders to use window space coordinates. This patch adds a shader_info field that tells the driver to use window space coordinates for a given vertex shader. It also enables this feature in radeonsi (the only NIR-capable driver that supported it in TGSI), and makes tgsi_to_nir aware of it. Signed-Off-By: Timur Kristóf Tested-by: Andre Heider Tested-by: Rob Clark Reviewed-by: Timothy Arceri Reviewed-by: Eric Anholt :04 04 3123b07ce063ffd4fee56974c64c130f3e617373 df57eb5bb70c0e46583399c73db499e1970fdd1b M src Reverting it fixed UH. Sorry, I don't have time for a ticket, yet 'cause I badly need some sleep... Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
Hello Tim, can you please send a patch to the list (and then we will see it at Patchwork Mesa, too), please? It is much faster (for me) and I haven't the time to dig me into Gitlab MRs etc. stuff at the moment. OLD school man... Thanks, Dieter Am 07.03.2019 11:16, schrieb Timur Kristóf: Hi, I was able to reproduce the problem with heaven, and that the proposed patch fixes it, so I made a MR: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/402 Best regards, Tim On Thu, 2019-03-07 at 08:27 +0100, Timur Kristóf wrote: Hi Dieter, Thanks for noticing this. I think I made a mistake by setting window_space_position the way I did. Should've only set that for vertex shaders. I believe this is the right thing to do: https://gitlab.freedesktop.org/Venemo/mesa/commit/4d8b97bacbe14bd6584d7a45ff98e65dfcb4c02b Still need to test it myself. If it works, I'll submit a MR. Let me know what you think. Best regards, Tim On Thu, 2019-03-07 at 05:45 +0100, Dieter Nützel wrote: > This commit (#317f10bf404) brake whole tessellation (empty parts of > the > screen) running UH under radeonsi NIR on Polaris 20 (RX580). > > 317f10bf404b562e1dda79c0636aee86beeccc2f is the first bad commit > commit 317f10bf404b562e1dda79c0636aee86beeccc2f > Author: Timur Kristóf > Date: Tue Feb 5 18:08:24 2019 +0100 > > nir: Add ability for shaders to use window space coordinates. > > This patch adds a shader_info field that tells the driver to > use > window > space coordinates for a given vertex shader. It also enables > this > feature > in radeonsi (the only NIR-capable driver that supported it in > TGSI), > and makes tgsi_to_nir aware of it. > > Signed-Off-By: Timur Kristóf > Tested-by: Andre Heider > Tested-by: Rob Clark > Reviewed-by: Timothy Arceri > Reviewed-by: Eric Anholt > > :04 04 3123b07ce063ffd4fee56974c64c130f3e617373 > df57eb5bb70c0e46583399c73db499e1970fdd1b M src > > Reverting it fixed UH. > > Sorry, I don't have time for a ticket, yet 'cause I badly need > some > sleep... > > Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] nir: Add ability for shaders to use window space coordinates - broken tessellation under NIR - bisected
Hello Andre, @Tim: Tested-by: Dieter Nützel with UH on Polaris 20 Am 07.03.2019 15:35, schrieb Andre Heider: On 07/03/2019 15:08, Dieter Nützel wrote: can you please send a patch to the list (and then we will see it at Patchwork Mesa, too), please? It is much faster (for me) and I haven't the time to dig me into Gitlab MRs etc. stuff at the moment. OLD school man... It's just a single patch in that MR. I know. Got it in the meantime. There is an 'Options' pulldown (Download | Email Patches | Plain Diff) on the 'page' of every commit. As with github, you can append .patch to the url: https://gitlab.freedesktop.org/Venemo/mesa/commit/24d534e355f54edb4b27451d0e4d92a1adb1669c.patch Or just `curl | git am`. Does that work for you? "Auch gut." ;-) Regards, Andre I'm learning... Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: remove sisched hack for talos
Am 15.03.2019 15:20, schrieb Samuel Pitoiset:
Results of my benchmarks are:
3 runs at 1080p:
GFX8: -1%
GFX9: -1.12%
3 runs at 4k:
GFX8: -2%
GFX9: -1.85%
I'm actually not sure if we want to remove it...
Yes, my hint is we should wait until Marek is back from vacation.
Running all the time with AMD_DEBUB (R600_DEBUG)=nir,sisched 'cause it's
worth it...
Dieter
On 3/15/19 11:25 AM, Timothy Arceri wrote:
This was added in 8a7d4092d260 but no longer seems to have any
impact on performance.
---
src/amd/vulkan/radv_device.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c
b/src/amd/vulkan/radv_device.c
index 9570c15af02..56421dbc74b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -499,15 +499,7 @@ radv_handle_per_app_options(struct radv_instance
*instance,
if (!name)
return;
- if (!strcmp(name, "Talos - Linux - 32bit") ||
- !strcmp(name, "Talos - Linux - 64bit")) {
- if (!(instance->debug_flags & RADV_DEBUG_NO_SISCHED)) {
- /* Force enable LLVM sisched for Talos because it looks
-* safe and it gives few more FPS.
-*/
- instance->perftest_flags |= RADV_PERFTEST_SISCHED;
- }
- } else if (!strcmp(name, "DOOM_VFR")) {
+ if (!strcmp(name, "DOOM_VFR")) {
/* Work around a Doom VFR game bug */
instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] radv: Implement VK_EXT_pipeline_creation_feedback. - sigfault - bisected
Hello Bas, sorry but your latest commit #5f5ac19f138 radv: Implement VK_EXT_pipeline_creation_feedback. sigfault with every Vulkan apps for me. Reverting it SOLVED it. 5f5ac19f138125b04d8ddedd6334b996f8925a4a is the first bad commit commit 5f5ac19f138125b04d8ddedd6334b996f8925a4a Author: Bas Nieuwenhuizen Date: Tue Mar 19 02:30:33 2019 +0100 radv: Implement VK_EXT_pipeline_creation_feedback. Does what it says on the tin. The per stage time is only an approximation due to linking and the Vega merged stages. Reviewed-by: Samuel Pitoiset :04 04 ea08bcac9b3630e10bf333c79227bcd0ed9a894b 0924580849d9bc268e47be1248311ff3b5488c86 M src I'm on the 'old' way compiling today: ./autogen.sh --prefix=/usr/local --with-dri-drivers="" --with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast --with-vulkan-drivers=radeon --enable-nine --enable-opencl --disable-opencl_icd --enable-libglvnd --enable-autotools /home/dieter> vkcube Speicherschutzverletzung (core dumped) /home/dieter> vkcubepp Speicherschutzverletzung (core dumped) [46339.977530] vkcube[29027]: segfault at 7ff7951ae840 ip 7ff795146569 sp 7ffda7d3d070 error 7 in libvulkan_radeon.so[7ff7950e4000+1cf000] [46339.977536] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 39 fb ff 03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 00 00 [46341.772768] vkcubepp[29040]: segfault at 7fde85d21840 ip 7fde85cb9569 sp 7ffeb679dfc0 error 7 in libvulkan_radeon.so[7fde85c57000+1cf000] [46341.772775] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 39 fb ff 03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 00 00 /home/dieter> vulkaninfo | less Speicherschutzverletzung (core dumped) == VULKANINFO == Vulkan Instance Version: 1.1.98 Instance Extensions: Instance Extensions count = 16 VK_EXT_acquire_xlib_display : extension revision 1 VK_EXT_debug_report : extension revision 9 VK_EXT_debug_utils : extension revision 1 VK_EXT_direct_mode_display : extension revision 1 VK_EXT_display_surface_counter : extension revision 1 VK_KHR_device_group_creation: extension revision 1 VK_KHR_display : extension revision 23 VK_KHR_external_fence_capabilities : extension revision 1 VK_KHR_external_memory_capabilities : extension revision 1 VK_KHR_external_semaphore_capabilities: extension revision 1 VK_KHR_get_display_properties2 : extension revision 1 VK_KHR_get_physical_device_properties2: extension revision 1 VK_KHR_get_surface_capabilities2: extension revision 1 VK_KHR_surface : extension revision 25 VK_KHR_xcb_surface : extension revision 6 VK_KHR_xlib_surface : extension revision 6 Layers: count = 0 === Presentable Surfaces: = GPU id : 0 (AMD RADV POLARIS10 (LLVM 9.0.0)) Surface type : VK_KHR_xcb_surface Formats:count = 2 B8G8R8A8_SRGB B8G8R8A8_UNORM Present Modes: count = 3 IMMEDIATE_KHR MAILBOX_KHR FIFO_KHR VkSurfaceCapabilitiesKHR: minImageCount = 2 maxImageCount = 0 currentExtent: width = 256 height = 256 minImageExtent: width = 256 height = 256 maxImageExtent: width = 256 height = 256 maxImageArrayLayers = 1 supportedTransform: VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR currentTransform: VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR supportedCompositeAlpha: VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR supportedUsageFlags: VK_IMAGE_USAGE_TRANSFER_SRC_BIT VK_IMAGE_USAGE_TRANSFER_DST_BIT VK_IMAGE_USAGE_SAMPLED_BIT VK_IMAGE_USAGE_STORAGE_BIT VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT VkSurfaceCapabilities2EXT: supportedSurfaceCounters: None GPU id : 0 (AMD RADV POLARIS10 (LLVM 9.0.0)) Surface type : VK_KHR_xlib_surface Formats:count = 2 B8G8R8A8_SRGB B8G8R8A8_UNORM Present Modes: count = 3 IMMEDIATE_KHR MAILBOX_KHR FIFO_KHR Stops, here. BTW 'vulkaninfo' sigfault for some days even without this commit for me. [-] VK_KHR_shader_draw_parameters : extension revision 1 VK_KHR_storage_buffer_storage_class : extension revision 1 VK_KHR_swa
Re: [Mesa-dev] [PATCH] Revert "mesa/extensions: restrict GL_OES_EGL_image to GLES"
Am 16.09.2015 23:00, schrieb Dave Airlie:
This reverts commit 48961fa3ba37999a6f8fd812458b735e39604a95.
glamor/Xwayland use this, the spec saying something when it
was written, and the fact that the comment says Mesa relies on it
hasn't changed.
Thank you Dave!
r600g - NI/Turks works again with glamor, now.
Soo,
Tested-by: Dieter Nützel
I also don't have a copy of this patch in my mail archive, which
seems wierd, did it get posted to mesa-dev?
Signed-off-by: Dave Airlie
---
src/mesa/main/extensions.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 767c50e..b2c88c3 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -307,7 +307,8 @@ static const struct extension extension_table[] = {
{ "GL_OES_depth_texture_cube_map",
o(OES_depth_texture_cube_map), ES2, 2012 },
{ "GL_OES_draw_texture",
o(OES_draw_texture), ES1, 2004 },
{ "GL_OES_EGL_sync",o(dummy_true),
ES1 | ES2, 2010 },
- { "GL_OES_EGL_image", o(OES_EGL_image),
ES1 | ES2, 2006 },
+ /* FIXME: Mesa expects GL_OES_EGL_image to be available in OpenGL
contexts. */
+ { "GL_OES_EGL_image", o(OES_EGL_image),
GL | ES1 | ES2, 2006 },
{ "GL_OES_EGL_image_external",
o(OES_EGL_image_external), ES1 | ES2, 2010 },
{ "GL_OES_element_index_uint", o(dummy_true),
ES1 | ES2, 2005 },
{ "GL_OES_fbo_render_mipmap", o(dummy_true),
ES1 | ES2, 2005 },
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] nir: some comment fixups
Am 18.09.2015 02:27, schrieb Rob Clark:
On Thu, Sep 17, 2015 at 8:03 PM, Timothy Arceri
wrote:
On Thu, 2015-09-17 at 18:20 -0400, Rob Clark wrote:
From: Rob Clark
Signed-off-by: Rob Clark
---
src/glsl/nir/nir.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index 297858a..9d8c3f4 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -1451,13 +1451,13 @@ typedef struct nir_shader_compiler_options {
} nir_shader_compiler_options;
typedef struct nir_shader {
- /** hash table of name -> uniform nir_variable */
+ /** list of uniforms (nir_variable) */
struct exec_list uniforms;
- /** hash table of name -> input nir_variable */
+ /** list of inputs (nir_variable) */
struct exec_list inputs;
- /** hash table of name -> output nir_variable */
+ /** list of outputs (nir_variable) */
struct exec_list outputs;
/** Set of driver-specific options for the shader.
@@ -1467,10 +1467,10 @@ typedef struct nir_shader {
*/
const struct nir_shader_compiler_options *options;
- /** list of global variables in the shader */
+ /** list of global variables in the shader (nir_variable) */
struct exec_list globals;
- /** list of system value variables in the shader */
+ /** list of system value variables in the shade (nir_variable)r
The above comment is broken. With that fixed both patches are:
Reviewed-by: Timothy Arceri
oh, whoops.. thanks, fixed and pushed
BR,
-R
Rob,
you committed the broken one...
-Dieter
*/
struct exec_list system_values;
struct exec_list functions; /** < list of nir_function */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: add varyings to resource list only with SSO
Am 07.10.2015 09:04, schrieb Tapani Pälli:
Varyings can be considered inputs or outputs of a program only when
SSO is in use. With multi-stage programs, inputs contain only inputs
for first stage and outputs contains outputs of the final shader stage.
I've tested that fix works for Assault Android Cactus (demo version)
and does not cause Piglit or CTS regressions in glGetProgramiv tests.
Following ES 3.1 CTS separate shader tests that do query properties
of varyings in SSO shader programs pass:
ES31-CTS.program_interface_query.separate-programs-vertex
ES31-CTS.program_interface_query.separate-programs-fragment
Signed-off-by: Tapani Pälli
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92122
Tested-by: Dieter Nützel
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92173
'broke WebGL-Water Caustics on NI/Turks (6670)'
---
src/glsl/linker.cpp | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 6df8d61..a97b4ef 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -3421,10 +3421,13 @@ build_program_resource_list(struct
gl_shader_program *shProg)
if (input_stage == MESA_SHADER_STAGES && output_stage == 0)
return;
- if (!add_packed_varyings(shProg, input_stage))
- return;
- if (!add_packed_varyings(shProg, output_stage))
- return;
+ /* Program interface needs to expose varyings in case of SSO. */
+ if (shProg->SeparateShader) {
+ if (!add_packed_varyings(shProg, input_stage))
+ return;
+ if (!add_packed_varyings(shProg, output_stage))
+ return;
+ }
/* Add inputs and outputs to the resource list. */
if (!add_interface_variables(shProg,
shProg->_LinkedShaders[input_stage]->ir,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: Enable GL_ARB_gpu_shader5 extension
Am 07.10.2015 19:13, schrieb Glenn Kennard: On Wed, 07 Oct 2015 19:04:15 +0200, Benjamin Bellec wrote: Hi Glenn, The series doesn't apply on current master. Regard. It's not meant to apply directly on master. Quoting from the notes in patch 1/2: This patch depends on prior patch: r600g/sb: Support gs5 sampler indexing I can send unified version for current master if some one will try. It includes needed patch from Tapani, too. glsl-add-varyings-to-resource-list-only-with-SSO.patch Nice work! Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa: Add MESA_VERBOSE=api for several indexed BindBuffer variants
Hello Jordan, after your last commit I get this: main/bufferobj.c: In function '_mesa_BindBufferRange': main/bufferobj.c:3918:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'GLintptr' [-Wformat=] _mesa_enum_to_string(target), index, buffer, offset, size); ^ main/bufferobj.c:3918:19: warning: format '%d' expects argument of type 'int', but argument 7 has type 'GLsizeiptr' [-Wformat=] CXXLDlibmesagallium.la Happy New Year! -Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] st/mesa: implement new DMA-buf based VDPAU interop v2 - REGRESSION on r600
Hello Christian,
after all this new VDPAU stuff, I get after ages (months/years) only
black window with
mplayer -vo vdpau /data/Filme/test.mkv
on r600, NI, Turks XT.
Switching between full screen and window mode ('F') the innner (black)
window part would be halved (wrong offset?).
I'll do bisecting and sending full bug report later, if needed.
Greetings,
Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] st/mesa: implement new DMA-buf based VDPAU interop v2 - REGRESSION on r600
Am 30.03.2016 08:20, schrieb Thomas H.P. Andersen:
On Wed, Mar 30, 2016 at 6:36 AM, Dieter Nützel
wrote:
Hello Christian,
after all this new VDPAU stuff, I get after ages (months/years) only
black window with
mplayer -vo vdpau /data/Filme/test.mkv
on r600, NI, Turks XT.
Switching between full screen and window mode ('F') the innner
(black) window part would be halved (wrong offset?).
I'll do bisecting and sending full bug report later, if needed.
Hi Dieter,
Can you check if the patch I just sent helps?
https://lists.freedesktop.org/archives/mesa-dev/2016-March/111211.html
Hello Thomas,
sorry not enough.
Greetings,
Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] st/mesa: implement new DMA-buf based VDPAU interop v2 - REGRESSION on r600
Am 30.03.2016 08:51, schrieb Dieter Nützel:
Am 30.03.2016 08:20, schrieb Thomas H.P. Andersen:
On Wed, Mar 30, 2016 at 6:36 AM, Dieter Nützel
wrote:
Hello Christian,
after all this new VDPAU stuff, I get after ages (months/years) only
black window with
mplayer -vo vdpau /data/Filme/test.mkv
on r600, NI, Turks XT.
Switching between full screen and window mode ('F') the innner
(black) window part would be halved (wrong offset?).
I'll do bisecting and sending full bug report later, if needed.
Hi Dieter,
Can you check if the patch I just sent helps?
https://lists.freedesktop.org/archives/mesa-dev/2016-March/111211.html
Hello Thomas,
sorry not enough.
Addendum:
With your fix
I now get copies of the desktop (like a snapshot) recursive halved with
every 'F' key press =>
Wrong pointer?
Christian should I enable any debug switches?
Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600: ignore PIPE_BIND_LINEAR in *_is_format_supported
Tested-by: Dieter Nützel Thanks! Am 30.03.2016 15:40, schrieb Christian König: From: Christian König Similar to radeonsi linear layout should work for all not compressed or depth/stencil formats. Fixes issues with VDPAU on r600. Signed-off-by: Christian König --- src/gallium/drivers/r600/evergreen_state.c | 5 + src/gallium/drivers/r600/r600_state.c | 5 + 2 files changed, 10 insertions(+) diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600/evergreen_state.c index 83313cb..6595267 100644 --- a/src/gallium/drivers/r600/evergreen_state.c +++ b/src/gallium/drivers/r600/evergreen_state.c @@ -299,6 +299,11 @@ boolean evergreen_is_format_supported(struct pipe_screen *screen, if (usage & PIPE_BIND_TRANSFER_WRITE) retval |= PIPE_BIND_TRANSFER_WRITE; + if ((usage & PIPE_BIND_LINEAR) && + !util_format_is_compressed(format) && + !(usage & PIPE_BIND_DEPTH_STENCIL)) + retval |= PIPE_BIND_LINEAR; + return retval == usage; } diff --git a/src/gallium/drivers/r600/r600_state.c b/src/gallium/drivers/r600/r600_state.c index f902619..3189a13 100644 --- a/src/gallium/drivers/r600/r600_state.c +++ b/src/gallium/drivers/r600/r600_state.c @@ -239,6 +239,11 @@ boolean r600_is_format_supported(struct pipe_screen *screen, if (usage & PIPE_BIND_TRANSFER_WRITE) retval |= PIPE_BIND_TRANSFER_WRITE; + if ((usage & PIPE_BIND_LINEAR) && + !util_format_is_compressed(format) && + !(usage & PIPE_BIND_DEPTH_STENCIL)) + retval |= PIPE_BIND_LINEAR; + return retval == usage; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] st/mesa: implement new DMA-buf based VDPAU interop v2 - REGRESSION on r600
Am 30.03.2016 17:21, schrieb Alex Deucher:
On Wed, Mar 30, 2016 at 11:18 AM, Dieter Nützel
wrote:
Am 30.03.2016 08:51, schrieb Dieter Nützel:
Am 30.03.2016 08:20, schrieb Thomas H.P. Andersen:
On Wed, Mar 30, 2016 at 6:36 AM, Dieter Nützel
wrote:
Hello Christian,
after all this new VDPAU stuff, I get after ages (months/years)
only
black window with
mplayer -vo vdpau /data/Filme/test.mkv
on r600, NI, Turks XT.
Switching between full screen and window mode ('F') the innner
(black) window part would be halved (wrong offset?).
I'll do bisecting and sending full bug report later, if needed.
Hi Dieter,
Can you check if the patch I just sent helps?
https://lists.freedesktop.org/archives/mesa-dev/2016-March/111211.html
Hello Thomas,
sorry not enough.
Addendum:
With your fix
I now get copies of the desktop (like a snapshot) recursive halved
with
every 'F' key press =>
Wrong pointer?
Christian should I enable any debug switches?
Do you have DRI3 enabled?
Sure... ;-)
But FIXED with both (Thomas' + Christian's latest) patches.
I've send my Tested-by.
Thanks Alex.
Cheers,
Dieter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600: ignore PIPE_BIND_LINEAR in *_is_format_supportedRe:
Am 30.03.2016 17:39, schrieb Dieter Nützel: Tested-by: Dieter Nützel Thanks! Next addendum: Tested-by stands. Little additional observation: When I switch between window vs full screen mode (the 'F' key) I see for some fractions of a sencond the whole scaled desktop image before the video overlay arise. So the zoom show some sort of 'flikering'. Is this fixable? with DRI3 ;-) -Dieter Am 30.03.2016 15:40, schrieb Christian König: From: Christian König Similar to radeonsi linear layout should work for all not compressed or depth/stencil formats. Fixes issues with VDPAU on r600. Signed-off-by: Christian König --- src/gallium/drivers/r600/evergreen_state.c | 5 + src/gallium/drivers/r600/r600_state.c | 5 + 2 files changed, 10 insertions(+) diff --git a/src/gallium/drivers/r600/evergreen_state.c b/src/gallium/drivers/r600/evergreen_state.c index 83313cb..6595267 100644 --- a/src/gallium/drivers/r600/evergreen_state.c +++ b/src/gallium/drivers/r600/evergreen_state.c @@ -299,6 +299,11 @@ boolean evergreen_is_format_supported(struct pipe_screen *screen, if (usage & PIPE_BIND_TRANSFER_WRITE) retval |= PIPE_BIND_TRANSFER_WRITE; + if ((usage & PIPE_BIND_LINEAR) && + !util_format_is_compressed(format) && + !(usage & PIPE_BIND_DEPTH_STENCIL)) + retval |= PIPE_BIND_LINEAR; + return retval == usage; } diff --git a/src/gallium/drivers/r600/r600_state.c b/src/gallium/drivers/r600/r600_state.c index f902619..3189a13 100644 --- a/src/gallium/drivers/r600/r600_state.c +++ b/src/gallium/drivers/r600/r600_state.c @@ -239,6 +239,11 @@ boolean r600_is_format_supported(struct pipe_screen *screen, if (usage & PIPE_BIND_TRANSFER_WRITE) retval |= PIPE_BIND_TRANSFER_WRITE; + if ((usage & PIPE_BIND_LINEAR) && + !util_format_is_compressed(format) && + !(usage & PIPE_BIND_DEPTH_STENCIL)) + retval |= PIPE_BIND_LINEAR; + return retval == usage; } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failed: mesa 746 - no member named 'BufferStream'
Am 31.03.2016 04:13, schrieb AppVeyor: BUILD MESA 746 FAILED [1] Commit b273958c74 by Timothy Arceri on 3/10/2016 5:41 AM: docs: mark xfb_* qualifiers as DONE\n\nReviewed-by: Dave Airlie Configure your notification preferences [2] Links: -- [1] https://ci.appveyor.com/project/jrfonseca-fdo/mesa/build/746 [2] https://ci.appveyor.com/notifications CC state_tracker/st_cb_xformfb.lo state_tracker/st_cb_xformfb.c: In function 'st_begin_transform_feedback': state_tracker/st_cb_xformfb.c:128:57: error: 'struct gl_transform_feedback_info' has no member named 'BufferStream' obj->shader_program->LinkedTransformFeedback.BufferStream[i]; ^ state_tracker/st_cb_xformfb.c: In function 'st_end_transform_feedback': state_tracker/st_cb_xformfb.c:207:54: error: 'struct gl_transform_feedback_info' has no member named 'BufferStream' obj->shader_program->LinkedTransformFeedback.BufferStream[i]; ^ Makefile:2873: recipe for target 'state_tracker/st_cb_xformfb.lo' failed make[4]: *** [state_tracker/st_cb_xformfb.lo] Error 1 Can't find 'BufferStream' anywhere else. -Dieter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
