[Mesa-dev] [MR] meson for windows
Hi, I just wanted to let anyone who might be interested but isn't following gitlab know that I've posted the latest iteration of my meson for windows series here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/986 Dylan signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 00/48] Meson for windows
For anyone following this who is interested, I've posted the latest version to
gitlab:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/986
Quoting Dylan Baker (2018-08-06 17:50:40)
> Mostly this is the same thing as before, just rebased on master. A couple of
> the
> patches from v2 have already landed. I've also fix the bad rebase of Erik's
> patch to use the python module for finding python, and updated the appveyor
> instance to work, and use msbuild instead of ninja.
>
> Dylan Baker (48):
> meson: always define libglapi
> add a git ignore for subprojects
> meson: add a zlib subproject
> meson: add a expat subproject
> gallium: fix ddebug on windows
> glapi: export glapi_destroy_multithread when building shared-glapi on
> windows
> glsl: fix general_ir_test with mingw
> meson: fix dl detection on non cygwin windows
> meson: build getopt when using msvc
> meson: Add a platform for windows
> meson: don't build glx or dri by default on windows
> meson: don't allow glvnd on windows
> meson: add windows compiler checks and libraries
> meson: Make shader-cache a trillean instead of boolean
> meson: Add windows defines to glapi
> meson: Add necessary defines for mesa_gallium on windows
> meson: build gallium gdi winsys
> meson: build wgl state tracker
> meson: build libgl-gdi target
> meson: build graw-gdi target
> meson: fix gallium-osmesa to build for windows
> meson: Don't check for posix_memalign on windows
> meson: Add support for wrapping llvm
> util/xmlconfig: include strndup.h for windows
> meson: fix pipe-loader compilation for windows
> meson: don't look for rt on windows
> meson: Add support for using win_flex and win_bison on windows
> meson: make nm binary optional
> meson: for incluse of inttypes.h for glcpp with msvc
> meson: disable sse4.1 optimizations with msvc
> meson: add switches for SWR with MSVC
> meson: don't define GLX_USE_TLS for windows
> meson: Add idep_getopt for tests
> util/tests: Use define instead of VLA
> meson: Don't build glsl cache_test for windows
> glsl/tests: define ssize_t on windows
> meson: Set visibility and compat args for graw
> meson: don't build gallium trivial tests on windows
> meson: Fix gtest linkage on msvc
> meson: disable graw tests on mingw
> meson: don't build or run mesa-sha1 test on windows
> tests/vma: fix build with MSVC
> meson: maintain names of shared API libraries
> meson: Use python module to find python2 on windows
> meson: Add linker arguments for windows
> appveyor: Add support for meson as well as scons
> appveyor: use chocolatey (cinst) to install winflexbison
> use msbuild instead of ninja
>
> appveyor.yml | 41 +-
> docs/meson.html | 66 +++
> meson.build | 389 --
> meson_options.txt | 12 +-
> src/compiler/glsl/glcpp/meson.build | 16 +-
> src/compiler/glsl/meson.build | 6 +-
> src/compiler/glsl/tests/blob_test.c | 4 +
> src/compiler/glsl/tests/general_ir_test.cpp | 14 +-
> src/compiler/glsl/tests/meson.build | 21 +-
> src/egl/meson.build | 2 +-
> src/gallium/auxiliary/meson.build | 6 +
> src/gallium/auxiliary/pipe-loader/meson.build | 9 +-
> src/gallium/drivers/swr/meson.build | 3 +-
> .../drivers/swr/rasterizer/jitter/meson.build | 13 +-
> src/gallium/meson.build | 14 +-
> src/gallium/state_trackers/osmesa/meson.build | 12 +-
> .../{osmesa => wgl}/meson.build | 32 +-
> .../{graw-xlib => graw-gdi}/meson.build | 21 +-
> src/gallium/targets/graw-null/meson.build | 2 +
> src/gallium/targets/graw-xlib/meson.build | 1 +
> .../{graw-xlib => libgl-gdi}/meson.build | 30 +-
> src/gallium/targets/osmesa/meson.build| 11 +-
> src/gallium/tests/meson.build | 11 +-
> .../{tests => winsys/sw/gdi}/meson.build | 12 +-
> src/gbm/meson.build | 2 +-
> src/{gallium/tests => getopt}/meson.build | 14 +-
> src/gtest/meson.build | 7 +
> src/mapi/es1api/meson.build | 14 +-
> src/mapi/es2api/meson.build | 14 +-
> src/mapi/glapi/glapi.h| 2 +-
> src/mapi/glapi/meson.build| 13 +-
> src/mapi/meson.build | 2 +
> src/mapi/shared-glapi/meson.build | 11 +-
> src/mesa/meson.build | 12 +-
> src/meson.build | 5 +
> src/util/meson.build | 21 +-
> src/util/tests/hash_table/clear.c | 13 +-
> src/util/tests/hash_table/delete_management.c | 13 +-
> src/util/tests/hash_table/insert_many.c | 11 +-
>
Re: [Mesa-dev] [PATCH] ac: use amdgpu-flat-work-group-size
Reviewed-by: Bas Nieuwenhuizen
Thanks!
On Fri, May 31, 2019 at 10:08 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/common/ac_llvm_util.c| 10 ++
> src/amd/common/ac_llvm_util.h| 1 +
> src/amd/vulkan/radv_nir_to_llvm.c| 7 ++-
> src/gallium/drivers/radeonsi/si_shader.c | 7 ++-
> 4 files changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
> index 5b701603ebb..c8a8bf146fe 100644
> --- a/src/amd/common/ac_llvm_util.c
> +++ b/src/amd/common/ac_llvm_util.c
> @@ -262,20 +262,30 @@ ac_dump_module(LLVMModuleRef module)
> void
> ac_llvm_add_target_dep_function_attr(LLVMValueRef F,
> const char *name, unsigned value)
> {
> char str[16];
>
> snprintf(str, sizeof(str), "0x%x", value);
> LLVMAddTargetDependentFunctionAttr(F, name, str);
> }
>
> +void ac_llvm_set_workgroup_size(LLVMValueRef F, unsigned size)
> +{
> + if (!size)
> + return;
> +
> + char str[32];
> + snprintf(str, sizeof(str), "%u,%u", size, size);
> + LLVMAddTargetDependentFunctionAttr(F, "amdgpu-flat-work-group-size",
> str);
> +}
> +
> unsigned
> ac_count_scratch_private_memory(LLVMValueRef function)
> {
> unsigned private_mem_vgprs = 0;
>
> /* Process all LLVM instructions. */
> LLVMBasicBlockRef bb = LLVMGetFirstBasicBlock(function);
> while (bb) {
> LLVMValueRef next = LLVMGetFirstInstruction(bb);
>
> diff --git a/src/amd/common/ac_llvm_util.h b/src/amd/common/ac_llvm_util.h
> index ca00540da80..18102be5207 100644
> --- a/src/amd/common/ac_llvm_util.h
> +++ b/src/amd/common/ac_llvm_util.h
> @@ -102,20 +102,21 @@ void ac_dump_module(LLVMModuleRef module);
> LLVMValueRef ac_llvm_get_called_value(LLVMValueRef call);
> bool ac_llvm_is_function(LLVMValueRef v);
> LLVMModuleRef ac_create_module(LLVMTargetMachineRef tm, LLVMContextRef ctx);
>
> LLVMBuilderRef ac_create_builder(LLVMContextRef ctx,
> enum ac_float_mode float_mode);
>
> void
> ac_llvm_add_target_dep_function_attr(LLVMValueRef F,
> const char *name, unsigned value);
> +void ac_llvm_set_workgroup_size(LLVMValueRef F, unsigned size);
>
> static inline unsigned
> ac_get_load_intr_attribs(bool can_speculate)
> {
> /* READNONE means writes can't affect it, while READONLY means that
> * writes can affect it. */
> return can_speculate ? AC_FUNC_ATTR_READNONE :
>AC_FUNC_ATTR_READONLY;
> }
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 341f6388f32..6f102647ba8 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -511,25 +511,22 @@ create_llvm_function(LLVMContextRef ctx, LLVMModuleRef
> module,
> ac_add_attr_dereferenceable(P, UINT64_MAX);
> }
> }
>
> if (options->address32_hi) {
> ac_llvm_add_target_dep_function_attr(main_function,
>
> "amdgpu-32bit-address-high-bits",
> options->address32_hi);
> }
>
> - if (max_workgroup_size) {
> - ac_llvm_add_target_dep_function_attr(main_function,
> -
> "amdgpu-max-work-group-size",
> -max_workgroup_size);
> - }
> + ac_llvm_set_workgroup_size(main_function, max_workgroup_size);
> +
> if (options->unsafe_math) {
> /* These were copied from some LLVM test. */
> LLVMAddTargetDependentFunctionAttr(main_function,
>"less-precise-fpmad",
>"true");
> LLVMAddTargetDependentFunctionAttr(main_function,
>"no-infs-fp-math",
>"true");
> LLVMAddTargetDependentFunctionAttr(main_function,
>"no-nans-fp-math",
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c
> b/src/gallium/drivers/radeonsi/si_shader.c
> index d2927d0254b..1ba6b8b6033 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -4276,25 +4276,22 @@ void si_create_function(struct si_shader_context *ctx,
> if (fninfo->assign[i])
> *fninfo->assign[i] = LLVMGetParam(ctx->main_fn, i);
> }
>
> if (ctx->screen->info.address32_hi) {
> ac_llvm_add_target_dep_function_attr(ctx->main_fn,
>
Re: [Mesa-dev] [PATCH 1/9] intel/blorp: Only double the fast-clear rect alignment on HSW
Thanks for reaching out to the HW team. Given that the internal
documentation was updated to set the Project field of this restriction
to HSW:GT3, what do you think about shortening the comment to mention
that? I'd like to give this a RB as is, but there are a lot of truth
claims I'd have to verify in order to do so..
-Nanley
On Mon, Dec 3, 2018 at 2:48 PM Jason Ekstrand wrote:
>
> I've received confirmation from the HW team that the extra doubling is only
> needed on Haswell GT3.
>
> On Tue, May 15, 2018 at 5:28 PM Jason Ekstrand wrote:
>>
>> The data in the commit message is a bit sketchy for Ivybridge. We don't
>> run dEQP or any of the CTSs on Ivybridge in CI so all the data we have
>> is piglit. On Haswell, piglit didn't catch anything so we don't have
>> anything to go off of for Ivybridge besides the fact that the restriction
>> wasn't added until Haswell.
>> ---
>> src/intel/blorp/blorp_clear.c | 66
>> ---
>> 1 file changed, 56 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
>> index 832e8ee..618625b 100644
>> --- a/src/intel/blorp/blorp_clear.c
>> +++ b/src/intel/blorp/blorp_clear.c
>> @@ -235,16 +235,62 @@ get_fast_clear_rect(const struct isl_device *dev,
>>x_scaledown = x_align / 2;
>>y_scaledown = y_align / 2;
>>
>> - /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel
>> - * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color
>> - * Clear of Non-MultiSampled Render Target Restrictions":
>> - *
>> - * Clear rectangle must be aligned to two times the number of
>> - * pixels in the table shown below due to 16x16 hashing across the
>> - * slice.
>> - */
>> - x_align *= 2;
>> - y_align *= 2;
>> + if (ISL_DEV_IS_HASWELL(dev)) {
>> + /* The following text was added in the Haswell PRM, "3D Media GPGPU
>> + * Engine" >> "MCS Buffer for Render Target(s)" >> Table "Color
>> Clear
>> + * of Non-MultiSampler Render Target Restrictions":
>> + *
>> + *"Clear rectangle must be aligned to two times the number of
>> + *pixels in the table shown below due to 16X16 hashing across
>> the
>> + *slice."
>> + *
>> + * It has persisted in the documentation for all platforms up until
>> + * Cannonlake and possibly even beyond. However, we believe that
>> it
>> + * is only needed on Haswell.
>> + *
>> + * There are a couple possible explanations for this restriction:
>> + *
>> + * 1) If you assume that the hardware is writing to the CCS as
>> + *bytes, then the x/y_align computed above gives you an
>> alignment
>> + *in the CCS of 8x8 bytes and, if 16x16 is needed for hashing,
>> we
>> + *need to multiply by 2.
>> + *
>> + * 2) Haswell is a bit unique in that it's CCS tiling does not line
>> + *up with Y-tiling on a cache-line granularity. Instead, it
>> has
>> + *an extra bit of swizzling in bit 9. Also, bit 6 swizzling
>> + *applies to the CCS on Haswell. This means that Haswell CTS
>> + *does not match on a cache-line granularity but it does match
>> on
>> + *a 2x2 cache line granularity.
>> + *
>> + * Clearly, the first explanation seems to follow documentation the
>> + * best but they may be related. In any case, empirical evidence
>> + * seems to confirm that it is, indeed required on Haswell.
>> + *
>> + * On Broadwell things get a bit stickier. Broadwell adds support
>> + * for mip-mapped CCS with an alignment in the CCS of 256x128.
>> For a
>> + * 32bpb main surface, the above computation will yield a x/y_align
>> + * of 128x128 for a Y-tiled main surface and 256x64 for X-tiled.
>> In
>> + * either case, if we double the alignment, we will get an
>> alignment
>> + * bigger than horizontal and vertical alignment of the CCS and
>> fast
>> + * clears of one LOD may leak into others.
>> + *
>> + * Starting with Skylake, the image alignment for the CCS is only
>> + * 128x64 which is exactly the x/h_align computed above if the main
>> + * surface has a 32bpb format. Also, the "Render Target Resolve"
>> + * page in the bspec (not the PRM) says, "The Resolve Rectangle
>> size
>> + * is same as Clear Rectangle size from SKL+". The x/y_align
>> + * computed above (without doubling) match the resolve rectangle
>> + * calculation perfectly.
>> + *
>> + * Finally, to confirm all this, a full test run was performed on
>> + * Feb. 9, 2018 with this doubling removed and the only platform
>> + * which
[Mesa-dev] [PATCH] ac: use amdgpu-flat-work-group-size
From: Marek Olšák
---
src/amd/common/ac_llvm_util.c| 10 ++
src/amd/common/ac_llvm_util.h| 1 +
src/amd/vulkan/radv_nir_to_llvm.c| 7 ++-
src/gallium/drivers/radeonsi/si_shader.c | 7 ++-
4 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 5b701603ebb..c8a8bf146fe 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -262,20 +262,30 @@ ac_dump_module(LLVMModuleRef module)
void
ac_llvm_add_target_dep_function_attr(LLVMValueRef F,
const char *name, unsigned value)
{
char str[16];
snprintf(str, sizeof(str), "0x%x", value);
LLVMAddTargetDependentFunctionAttr(F, name, str);
}
+void ac_llvm_set_workgroup_size(LLVMValueRef F, unsigned size)
+{
+ if (!size)
+ return;
+
+ char str[32];
+ snprintf(str, sizeof(str), "%u,%u", size, size);
+ LLVMAddTargetDependentFunctionAttr(F, "amdgpu-flat-work-group-size",
str);
+}
+
unsigned
ac_count_scratch_private_memory(LLVMValueRef function)
{
unsigned private_mem_vgprs = 0;
/* Process all LLVM instructions. */
LLVMBasicBlockRef bb = LLVMGetFirstBasicBlock(function);
while (bb) {
LLVMValueRef next = LLVMGetFirstInstruction(bb);
diff --git a/src/amd/common/ac_llvm_util.h b/src/amd/common/ac_llvm_util.h
index ca00540da80..18102be5207 100644
--- a/src/amd/common/ac_llvm_util.h
+++ b/src/amd/common/ac_llvm_util.h
@@ -102,20 +102,21 @@ void ac_dump_module(LLVMModuleRef module);
LLVMValueRef ac_llvm_get_called_value(LLVMValueRef call);
bool ac_llvm_is_function(LLVMValueRef v);
LLVMModuleRef ac_create_module(LLVMTargetMachineRef tm, LLVMContextRef ctx);
LLVMBuilderRef ac_create_builder(LLVMContextRef ctx,
enum ac_float_mode float_mode);
void
ac_llvm_add_target_dep_function_attr(LLVMValueRef F,
const char *name, unsigned value);
+void ac_llvm_set_workgroup_size(LLVMValueRef F, unsigned size);
static inline unsigned
ac_get_load_intr_attribs(bool can_speculate)
{
/* READNONE means writes can't affect it, while READONLY means that
* writes can affect it. */
return can_speculate ? AC_FUNC_ATTR_READNONE :
AC_FUNC_ATTR_READONLY;
}
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
b/src/amd/vulkan/radv_nir_to_llvm.c
index 341f6388f32..6f102647ba8 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -511,25 +511,22 @@ create_llvm_function(LLVMContextRef ctx, LLVMModuleRef
module,
ac_add_attr_dereferenceable(P, UINT64_MAX);
}
}
if (options->address32_hi) {
ac_llvm_add_target_dep_function_attr(main_function,
"amdgpu-32bit-address-high-bits",
options->address32_hi);
}
- if (max_workgroup_size) {
- ac_llvm_add_target_dep_function_attr(main_function,
-
"amdgpu-max-work-group-size",
-max_workgroup_size);
- }
+ ac_llvm_set_workgroup_size(main_function, max_workgroup_size);
+
if (options->unsafe_math) {
/* These were copied from some LLVM test. */
LLVMAddTargetDependentFunctionAttr(main_function,
"less-precise-fpmad",
"true");
LLVMAddTargetDependentFunctionAttr(main_function,
"no-infs-fp-math",
"true");
LLVMAddTargetDependentFunctionAttr(main_function,
"no-nans-fp-math",
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index d2927d0254b..1ba6b8b6033 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4276,25 +4276,22 @@ void si_create_function(struct si_shader_context *ctx,
if (fninfo->assign[i])
*fninfo->assign[i] = LLVMGetParam(ctx->main_fn, i);
}
if (ctx->screen->info.address32_hi) {
ac_llvm_add_target_dep_function_attr(ctx->main_fn,
"amdgpu-32bit-address-high-bits",
ctx->screen->info.address32_hi);
}
- if (max_workgroup_size) {
- ac_llvm_add_target_dep_function_attr(ctx->main_fn,
-
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
I see. Rb for the whole patch then.
Marek
On Fri, May 31, 2019, 2:24 PM Rhys Perry wrote:
> The first and last hunks are needed to pass on the shader_info to the
> middle hunk, which needs it so that it can test if the compute shader
> has a derivative group.
>
> On Fri, 31 May 2019 at 18:38, Marek Olšák wrote:
> >
> > The first and last hunks look like they shouldn't be there. Other than
> that:
> >
> > Reviewed-by: Marek Olšák
> >
> > Marek
> >
> > On Fri, May 31, 2019 at 11:53 AM Rhys Perry
> wrote:
> >>
> >> Otherwise LLVM can sink them and their texture coordinate calculations
> >> into divergent branches.
> >>
> >> v2: simplify the conditions on which the intrinsic is marked as
> convergent
> >> v3: only mark as convergent in FS and CS with derivative groups
> >>
> >> Cc:
> >> Signed-off-by: Rhys Perry
> >> ---
> >> src/amd/common/ac_nir_to_llvm.c | 18 ++
> >> 1 file changed, 18 insertions(+)
> >>
> >> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> >> index 265e3b636c4..9e9fade7227 100644
> >> --- a/src/amd/common/ac_nir_to_llvm.c
> >> +++ b/src/amd/common/ac_nir_to_llvm.c
> >> @@ -38,6 +38,7 @@ struct ac_nir_context {
> >> struct ac_shader_abi *abi;
> >>
> >> gl_shader_stage stage;
> >> + shader_info *info;
> >>
> >> LLVMValueRef *ssa_defs;
> >>
> >> @@ -1394,6 +1395,22 @@ static LLVMValueRef build_tex_intrinsic(struct
> ac_nir_context *ctx,
> >> }
> >>
> >> args->attributes = AC_FUNC_ATTR_READNONE;
> >> + bool cs_derivs = ctx->stage == MESA_SHADER_COMPUTE &&
> >> +ctx->info->cs.derivative_group !=
> DERIVATIVE_GROUP_NONE;
> >> + if (ctx->stage == MESA_SHADER_FRAGMENT || cs_derivs) {
> >> + /* Prevent texture instructions with implicit
> derivatives from being
> >> +* sinked into branches. */
> >> + switch (instr->op) {
> >> + case nir_texop_tex:
> >> + case nir_texop_txb:
> >> + case nir_texop_lod:
> >> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> >> + break;
> >> + default:
> >> + break;
> >> + }
> >> + }
> >> +
> >> return ac_build_image_opcode(>ac, args);
> >> }
> >>
> >> @@ -4350,6 +4367,7 @@ void ac_nir_translate(struct ac_llvm_context *ac,
> struct ac_shader_abi *abi,
> >> ctx.abi = abi;
> >>
> >> ctx.stage = nir->info.stage;
> >> + ctx.info = >info;
> >>
> >> ctx.main_function = LLVMGetBasicBlockParent(LLVMGetInsertBlock(
> ctx.ac.builder));
> >>
> >> --
> >> 2.21.0
> >>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110468] using swrAVX renders incorrectly at particular resolutions
https://bugs.freedesktop.org/show_bug.cgi?id=110468
--- Comment #3 from Krzysztof Raszkowski ---
(In reply to ayan908 from comment #0)
> Created attachment 144032 [details]
> WGLINFO
>
> At certain resolutions (360p, 720p, 1080p, 1440p and possibly others), the
> rendering is incorrect with GALLIUM_DRIVER=swr, using swrAVX.dll. For
> example, simply drawing a rectangle with glDrawElements results in an
> incorrectly rendered result. This works perfectly natively (with Intel's
> drivers) and with llvmpipe.
>
>
> Steps to reproduce:
>
> 1) Create a window at 720p, OpenGL 3.3 Core.
> 2) Use the code below to set up the rectangle.
> 3) Draw the rectangle using glDrawElements.
>
>
> Code (Unfortunately, I do not know how to use glut so the window creation
> and rendering loop has been omitted):
> #include
>
>
> int main()
> {
> // Set up OpenGL context
> // OpenGL 3.3 core, 720p
>
> GLuint vao, vbo, ibo;
> GLfloat position[] =
> {
> -0.5f, -0.5f, 0.0f,
> 0.5f, -0.5f, 0.0f,
> 0.5f, 0.5f, 0.0f,
> -0.5f, 0.5f, 0.0f
> };
>
>
> GLuint indices[] =
> {
> 0, 1, 2,
> 0, 2, 3
> };
>
>
> glGenVertexArrays(1, );
> glBindVertexArray(vao);
>
> glGenBuffers(1, );
> glBindBuffer(GL_ARRAY_BUFFER, vbo);
> glBufferData(GL_ARRAY_BUFFER, sizeof(position), position,
> GL_STATIC_DRAW);
> glEnableVertexAttribArray(0);
> glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), 0);
>
>
> glGenBuffers(1, );
> glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
> glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices,
> GL_STATIC_DRAW);
>
> GLuint vertex = glCreateShader(GL_VERTEX_SHADER), fragment =
> glCreateShader(GL_FRAGMENT_SHADER);
>
>
> {
>
> const char* shaderSource =
> "#version 330 core\n"
> "layout(location = 0) in vec3 position;\n"
> "\n"
> "void main()\n"
> "{\n"
> "gl_Position = vec4(position, 1.0);\n"
> "}\n"
> "";
>
>
> glShaderSource(vertex, 1, , 0);
> glCompileShader(vertex);
>
> // Check compile status
>
> }
>
> {
>
> const char* shaderSource =
> "#version 330 core\n"
> "layout(location = 0) out vec4 col;\n"
> "\n"
> "void main()\n"
> "{\n"
> "col = vec4(0.3, 0.8, 0.2, 1.0);\n"
> "}\n"
> "";
>
>
> glShaderSource(fragment, 1, , 0);
> glCompileShader(fragment);
>
> // Check compile status
> }
>
> GLuint program = glCreateProgram();
> glAttachShader(program, vertex);
> glAttachShader(program, fragment);
>
> glLinkProgram(program);
> glValidateProgram(program);
>
> // Check link status
> glUseProgram(program);
>
> // Render using glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);
>
> }
Hi,
Tried on win10 (mesa from
https://gitlab.freedesktop.org/mesa/mesa/commit/5441d562433a6315ca00c0c69160ff848e5ec34a
build using scons + MSVC + LLVM 6.0.1) and works fine with 720p and swr.
Could you attach wglinfo output with GALLIUM_DRIVER=swr?
Could you describe more how mesa was build (build parameters, compiler name,
version etc.)?
Could you describe your environment (env variables, OS version)?
Thanks,
Krzysztof
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
The first and last hunks are needed to pass on the shader_info to the
middle hunk, which needs it so that it can test if the compute shader
has a derivative group.
On Fri, 31 May 2019 at 18:38, Marek Olšák wrote:
>
> The first and last hunks look like they shouldn't be there. Other than that:
>
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Fri, May 31, 2019 at 11:53 AM Rhys Perry wrote:
>>
>> Otherwise LLVM can sink them and their texture coordinate calculations
>> into divergent branches.
>>
>> v2: simplify the conditions on which the intrinsic is marked as convergent
>> v3: only mark as convergent in FS and CS with derivative groups
>>
>> Cc:
>> Signed-off-by: Rhys Perry
>> ---
>> src/amd/common/ac_nir_to_llvm.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 265e3b636c4..9e9fade7227 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -38,6 +38,7 @@ struct ac_nir_context {
>> struct ac_shader_abi *abi;
>>
>> gl_shader_stage stage;
>> + shader_info *info;
>>
>> LLVMValueRef *ssa_defs;
>>
>> @@ -1394,6 +1395,22 @@ static LLVMValueRef build_tex_intrinsic(struct
>> ac_nir_context *ctx,
>> }
>>
>> args->attributes = AC_FUNC_ATTR_READNONE;
>> + bool cs_derivs = ctx->stage == MESA_SHADER_COMPUTE &&
>> +ctx->info->cs.derivative_group !=
>> DERIVATIVE_GROUP_NONE;
>> + if (ctx->stage == MESA_SHADER_FRAGMENT || cs_derivs) {
>> + /* Prevent texture instructions with implicit derivatives
>> from being
>> +* sinked into branches. */
>> + switch (instr->op) {
>> + case nir_texop_tex:
>> + case nir_texop_txb:
>> + case nir_texop_lod:
>> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
>> + break;
>> + default:
>> + break;
>> + }
>> + }
>> +
>> return ac_build_image_opcode(>ac, args);
>> }
>>
>> @@ -4350,6 +4367,7 @@ void ac_nir_translate(struct ac_llvm_context *ac,
>> struct ac_shader_abi *abi,
>> ctx.abi = abi;
>>
>> ctx.stage = nir->info.stage;
>> + ctx.info = >info;
>>
>> ctx.main_function =
>> LLVMGetBasicBlockParent(LLVMGetInsertBlock(ctx.ac.builder));
>>
>> --
>> 2.21.0
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
The first and last hunks look like they shouldn't be there. Other than that:
Reviewed-by: Marek Olšák
Marek
On Fri, May 31, 2019 at 11:53 AM Rhys Perry
wrote:
> Otherwise LLVM can sink them and their texture coordinate calculations
> into divergent branches.
>
> v2: simplify the conditions on which the intrinsic is marked as convergent
> v3: only mark as convergent in FS and CS with derivative groups
>
> Cc:
> Signed-off-by: Rhys Perry
> ---
> src/amd/common/ac_nir_to_llvm.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 265e3b636c4..9e9fade7227 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -38,6 +38,7 @@ struct ac_nir_context {
> struct ac_shader_abi *abi;
>
> gl_shader_stage stage;
> + shader_info *info;
>
> LLVMValueRef *ssa_defs;
>
> @@ -1394,6 +1395,22 @@ static LLVMValueRef build_tex_intrinsic(struct
> ac_nir_context *ctx,
> }
>
> args->attributes = AC_FUNC_ATTR_READNONE;
> + bool cs_derivs = ctx->stage == MESA_SHADER_COMPUTE &&
> +ctx->info->cs.derivative_group !=
> DERIVATIVE_GROUP_NONE;
> + if (ctx->stage == MESA_SHADER_FRAGMENT || cs_derivs) {
> + /* Prevent texture instructions with implicit derivatives
> from being
> +* sinked into branches. */
> + switch (instr->op) {
> + case nir_texop_tex:
> + case nir_texop_txb:
> + case nir_texop_lod:
> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> + break;
> + default:
> + break;
> + }
> + }
> +
> return ac_build_image_opcode(>ac, args);
> }
>
> @@ -4350,6 +4367,7 @@ void ac_nir_translate(struct ac_llvm_context *ac,
> struct ac_shader_abi *abi,
> ctx.abi = abi;
>
> ctx.stage = nir->info.stage;
> + ctx.info = >info;
>
> ctx.main_function = LLVMGetBasicBlockParent(LLVMGetInsertBlock(
> ctx.ac.builder));
>
> --
> 2.21.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 --- Comment #7 from network...@rkmail.ru --- (In reply to network723 from comment #6) > If I keep textures at "medium", cant set > everything else to ultra and still get 120+ fps. I *can* set, obvious fix. Also, intensive real-gameplay testing showed only 75+ fps on ultras, but it's still much better than RX480. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 --- Comment #6 from network...@rkmail.ru --- I've updated to mesa git master 0e1c5cc78fe24fb9620cac7bdcf7e927ab042ff8, no changes. Also, I noticed, performance is only low if "Textures" setting of the game is set to anything above "medium". If I keep textures at "medium", cant set everything else to ultra and still get 120+ fps. I wonder if it has to do something with VRAM size, Vega20 has 16GiB, while RX480 and older Vega56/65 have only 8GiB... -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] etnaviv: fix some pm query issues
The offsets to read the query results were off-by-one, which causes the
counters to report bogus increasing values.
Also the counter result is u32, so we need to initialize the query type
to reflect that.
Signed-off-by: Lucas Stach
---
This only fixes the obvious issues. I still believe there are some
GPU/CPU synchronization issues in this code, that need to be fixed
separately.
---
src/gallium/drivers/etnaviv/etnaviv_query_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
b/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
index ade0b9790c28..c63ed8304919 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_query_pm.c
@@ -485,9 +485,9 @@ etna_pm_query_get(struct etna_cmd_stream *stream, struct
etna_query *q,
assert(flags);
if (flags == ETNA_PM_PROCESS_PRE)
- offset = 2;
+ offset = 1;
else
- offset = 3;
+ offset = 2;
struct etna_perf p = {
.flags = flags,
@@ -639,6 +639,10 @@ etna_pm_get_driver_query_info(struct pipe_screen *pscreen,
unsigned index,
info->name = query_config[i].name;
info->query_type = query_config[i].type;
info->group_id = query_config[i].group_id;
+ info->type = PIPE_DRIVER_QUERY_TYPE_UINT;
+ info->result_type = PIPE_DRIVER_QUERY_RESULT_TYPE_AVERAGE;
+ info->max_value.u32 = 0;
+ info->flags = 0;
return 1;
}
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
Otherwise LLVM can sink them and their texture coordinate calculations
into divergent branches.
v2: simplify the conditions on which the intrinsic is marked as convergent
v3: only mark as convergent in FS and CS with derivative groups
Cc:
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 265e3b636c4..9e9fade7227 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -38,6 +38,7 @@ struct ac_nir_context {
struct ac_shader_abi *abi;
gl_shader_stage stage;
+ shader_info *info;
LLVMValueRef *ssa_defs;
@@ -1394,6 +1395,22 @@ static LLVMValueRef build_tex_intrinsic(struct
ac_nir_context *ctx,
}
args->attributes = AC_FUNC_ATTR_READNONE;
+ bool cs_derivs = ctx->stage == MESA_SHADER_COMPUTE &&
+ctx->info->cs.derivative_group !=
DERIVATIVE_GROUP_NONE;
+ if (ctx->stage == MESA_SHADER_FRAGMENT || cs_derivs) {
+ /* Prevent texture instructions with implicit derivatives from
being
+* sinked into branches. */
+ switch (instr->op) {
+ case nir_texop_tex:
+ case nir_texop_txb:
+ case nir_texop_lod:
+ args->attributes |= AC_FUNC_ATTR_CONVERGENT;
+ break;
+ default:
+ break;
+ }
+ }
+
return ac_build_image_opcode(>ac, args);
}
@@ -4350,6 +4367,7 @@ void ac_nir_translate(struct ac_llvm_context *ac, struct
ac_shader_abi *abi,
ctx.abi = abi;
ctx.stage = nir->info.stage;
+ ctx.info = >info;
ctx.main_function =
LLVMGetBasicBlockParent(LLVMGetInsertBlock(ctx.ac.builder));
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Don't flip scanout
> Guess there's some flipping in stencil and *coord that needs to be unflipped? Looks like it, thank you. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] panfrost: Don't flip scanout
On Tue, 28 May 2019 at 08:17, Tomeu Vizoso wrote:
>
> On 5/26/19 1:51 AM, Alyssa Rosenzweig wrote:
> > The mesa/st flips the viewport, so we respect that rather than
> > trying to flip the framebuffer itself and ignoring the viewport and
> > using a messy heuristic.
> >
> > However, this brings an underlying disagreement about the interpretation
> > of winding order to light. The blob uses a different strategy than Mesa
> > for handling viewport Y flipping, so the meanings of the winding order
> > bit are flipped for it. To keep things clean on our end, we rename to
> > explicitly use Gallium (rather than flipped OpenGL) conventions.
> >
> > Fixes upside-down Xwayland/egl windows.
> >
> > Suggested-by: Rob Clark
> > Signed-off-by: Alyssa Rosenzweig
> > Cc: Tomeu Vizoso
>
> This is a great cleanup, thanks!
>
> Reviewed-by: Tomeu Vizoso
Actually, the CI has found these regressions:
dEQP-GLES2.functional.fbo.render.resize.rbo_rgb565_stencil_index8
dEQP-GLES2.functional.fbo.render.stencil_clear.rbo_rgb565_stencil_index8
dEQP-GLES2.functional.fbo.render.stencil_clear.tex2d_rgb_stencil_index8
dEQP-GLES2.functional.fbo.render.stencil_clear.tex2d_rgba_stencil_index8
dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_xyz
dEQP-GLES2.functional.shaders.builtin_variable.pointcoord
Guess there's some flipping in stencil and *coord that needs to be unflipped?
Thanks,
Tomeu
> Cheers,
>
> Tomeu
>
>
> > ---
> > .../drivers/panfrost/include/panfrost-job.h | 8 +--
> > src/gallium/drivers/panfrost/pan_context.c| 54 +++
> > src/gallium/drivers/panfrost/pan_context.h| 7 +--
> > src/gallium/drivers/panfrost/pan_fragment.c | 7 +--
> > src/gallium/drivers/panfrost/pan_mfbd.c | 16 ++
> > src/gallium/drivers/panfrost/pan_sfbd.c | 17 ++
> > .../drivers/panfrost/pandecode/decode.c | 12 ++---
> > 7 files changed, 40 insertions(+), 81 deletions(-)
> >
> > diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
> > b/src/gallium/drivers/panfrost/include/panfrost-job.h
> > index f4f145890de..8a4a7644070 100644
> > --- a/src/gallium/drivers/panfrost/include/panfrost-job.h
> > +++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
> > @@ -73,9 +73,11 @@ enum mali_draw_mode {
> > #define MALI_OCCLUSION_QUERY(1 << 3)
> > #define MALI_OCCLUSION_PRECISE (1 << 4)
> >
> > -#define MALI_FRONT_FACE(v) (v << 5)
> > -#define MALI_CCW (0)
> > -#define MALI_CW (1)
> > +/* Set for a glFrontFace(GL_CCW) in a Y=0=TOP coordinate system (like
> > Gallium).
> > + * In OpenGL, this would corresponds to glFrontFace(GL_CW). Mesa and the
> > blob
> > + * disagree about how to do viewport flipping, so the blob actually sets
> > this
> > + * for GL_CW but then has a negative viewport stride */
> > +#define MALI_FRONT_CCW_TOP (1 << 5)
> >
> > #define MALI_CULL_FACE_FRONT(1 << 6)
> > #define MALI_CULL_FACE_BACK (1 << 7)
> > diff --git a/src/gallium/drivers/panfrost/pan_context.c
> > b/src/gallium/drivers/panfrost/pan_context.c
> > index 5cae386f070..d0170a63def 100644
> > --- a/src/gallium/drivers/panfrost/pan_context.c
> > +++ b/src/gallium/drivers/panfrost/pan_context.c
> > @@ -1143,15 +1143,6 @@ panfrost_emit_for_draw(struct panfrost_context *ctx,
> > bool with_vertex_data)
> >
> > const struct pipe_viewport_state *vp = >pipe_viewport;
> >
> > -/* For flipped-Y buffers (signaled by negative scale), the
> > translate is
> > - * flipped as well */
> > -
> > -bool invert_y = vp->scale[1] < 0.0;
> > -float translate_y = vp->translate[1];
> > -
> > -if (invert_y)
> > -translate_y = ctx->pipe_framebuffer.height - translate_y;
> > -
> > for (int i = 0; i <= PIPE_SHADER_FRAGMENT; ++i) {
> > struct panfrost_constant_buffer *buf =
> > >constant_buffer[i];
> >
> > @@ -1171,11 +1162,11 @@ panfrost_emit_for_draw(struct panfrost_context
> > *ctx, bool with_vertex_data)
> >
> > if (sysval == PAN_SYSVAL_VIEWPORT_SCALE) {
> > uniforms[4*i + 0] = vp->scale[0];
> > -uniforms[4*i + 1] = fabsf(vp->scale[1]);
> > +uniforms[4*i + 1] = vp->scale[1];
> > uniforms[4*i + 2] = vp->scale[2];
> > } else if (sysval == PAN_SYSVAL_VIEWPORT_OFFSET) {
> > uniforms[4*i + 0] = vp->translate[0];
> > -uniforms[4*i + 1] = translate_y;
> > +uniforms[4*i + 1] = vp->translate[1];
> > uniforms[4*i + 2] = vp->translate[2];
> > } else {
> > assert(0);
> > @@ -1245,24 +1236,28 @@ panfrost_emit_for_draw(struct panfrost_context
> > *ctx, bool with_vertex_data)
> > view.viewport0[0] = (int)
[Mesa-dev] [PATCH] radeonsi/nir: Fix type in bindless address computation
Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM. --- With this patch, we now have Piglit parity in debug mode. src/gallium/drivers/radeonsi/si_shader_nir.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c b/src/gallium/drivers/radeonsi/si_shader_nir.c index 19ed71ae05d..72e6ffbac8a 100644 --- a/src/gallium/drivers/radeonsi/si_shader_nir.c +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c @@ -1020,7 +1020,7 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi, * 16-dword slots for now. */ dynamic_index = LLVMBuildMul(ctx->ac.builder, dynamic_index, -LLVMConstInt(ctx->i32, 2, 0), ""); +LLVMConstInt(ctx->i64, 2, 0), ""); return si_load_image_desc(ctx, list, dynamic_index, desc_type, dcc_off, true); @@ -1032,7 +1032,7 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi, * to prevent incorrect code generation and hangs. */ dynamic_index = LLVMBuildMul(ctx->ac.builder, dynamic_index, -LLVMConstInt(ctx->i32, 2, 0), ""); +LLVMConstInt(ctx->i64, 2, 0), ""); list = ac_build_pointer_add(>ac, list, dynamic_index); return si_load_sampler_desc(ctx, list, ctx->i32_0, desc_type); } -- 2.17.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] EVOC Proposal.
Hello. I am an Engineering student from Mumbai, India. i have gone through the project idea on Piglit for Openmax on the X.org project list and found it interesting. I am comfortable with both C and Python, and I am confident of accomplishing the project. Your guidance, as well as criticism on the project/proposal would be helpuful. -- Regards, Adarsh Khubchandani EVOC APPLICATION.pdf Description: Adobe PDF document ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Zero-Copy Texture usage from OpenCL
Hi, Can someone please help to validate below MESA features. "system shall allow 3D rendering to make use of OpenCL buffers in a zero-copy manner" "system shall allow 3D rendering to make use of Media SDK buffers in a zero-copy manner." Thanks, Shiva ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110357] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 Andrés Gómez García changed: What|Removed |Added Summary|[REGRESSION] [BISECTED] |[BISECTED] [OpenGL CTS] |[OpenGL CTS] cts-runner |cts-runner --type=gl46 |--type=gl46 fails in new|fails in new attempted "41" |attempted "41" |configuration |configuration | -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Crash in iris_bufmgr.c
Kenneth, > Ouch. Thanks for letting me know. Fixed by: > > commit 53878f7a8989879b0f3ca37df9fd1fb37f2525ca > Author: Kenneth Graunke > Date: Wed May 29 23:20:31 2019 -0700 > > iris: Be lazy about cleaning up purged BOs in the cache. > Thanks for fixing! Works again! best Mathias ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
