Re: [Mesa-dev] [PATCH] gbm: add support for loading third-party backend

On 25/01/17 07:34 PM, Yu, Qiang wrote: >> From: Michel Dänzer >> On 24/01/17 12:36 PM, Qiang Yu wrote: >>> Third-party can put their backend to a directory configured with >>> '--with-gbm-backenddir' and create a /etc/gbm.conf.d/*.conf file >>> which contains the backend so

[Mesa-dev] [PATCH] radv: drop support for VK_AMD_NEGATIVE_VIEWPORT_HEIGHT

This extension was not correctly supported, and it conflicts with the VK_KHR_MAINTENANCE1 spec. --- src/amd/vulkan/radv_device.c | 4 1 file changed, 4 deletions(-) diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c index 7f68cdc..9f05dd6 100644 ---

[Mesa-dev] [PATCH 3/7] radv: use new error codes for AllocateDescriptorSets

There is a new error code in Maintenance1 that is more specific to the situation: VK_ERROR_OUT_OF_POOL_MEMORY_KHR Fixes CTS test case: dEQP-VK.api.descriptor_pool.out_of_pool_memory --- src/amd/vulkan/radv_descriptor_set.c | 2 +- src/amd/vulkan/radv_util.c | 1 + 2 files changed, 2

[Mesa-dev] [PATCH 1/7] radv: add trim command pool stub

--- src/amd/vulkan/radv_cmd_buffer.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index c62d275..0b090b7 100644 --- a/src/amd/vulkan/radv_cmd_buffer.c +++ b/src/amd/vulkan/radv_cmd_buffer.c @@ -1895,6 +1895,13 @@

[Mesa-dev] [PATCH 6/7] radv: Fix vkCmdCopyImage for 2d slices into 3d Images

Previously the z offset of the destination image was being ignored. It should be taken into account when copying into a 3d target. Also, img_extent_el.depth was being incorrectly clamped to 1 due to the source image being VK_IMAGE_TYPE_2D. This would result in the blit failing to iterate over all

[Mesa-dev] [PATCH 4/7] radv: Don't allow any operations on non-supported depth/stencil formats.

From: Bas Nieuwenhuizen We really use the depth block for the blits. Signed-off-by: Bas Nieuwenhuizen --- src/amd/vulkan/radv_formats.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/amd/vulkan/radv_formats.c

[Mesa-dev] [PATCH 7/7] radv: Expose VK_KHR_maintenance1

--- src/amd/vulkan/radv_device.c | 4 1 file changed, 4 insertions(+) diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c index 4aa6af2..7f68cdc 100644 --- a/src/amd/vulkan/radv_device.c +++ b/src/amd/vulkan/radv_device.c @@ -104,6 +104,10 @@ static const

[Mesa-dev] radv: Implement VK_KHR_maintenance1

This series implements the VK_KHR_maintenance1 extension. It is loosely based on jekstrand's series for anv. This series soft depends on one of Bas's patches that are not yet in master. I'm not certain of protocol for this kind of situation. I've left them included in this series, but if I should

[Mesa-dev] [PATCH 5/7] radv: Expose transfer format features.

From: Bas Nieuwenhuizen Signed-off-by: Bas Nieuwenhuizen --- src/amd/vulkan/radv_formats.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c index f56f67c..c968cef 100644

[Mesa-dev] [PATCH 2/7] radv: vkAllocateCommandBuffers should NULL all output handles

This is part of the spec and fixes CTS tests: dEQP-VK.api.object_management.alloc_callback_fail_multiple.command_buffer_* --- src/amd/vulkan/radv_cmd_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index

Re: [Mesa-dev] [PATCH 2/2] gallium/radeon: add VRAM-vis-usage HUD query

Question more about the first one [Mesa-dev] [PATCH 1/2] gallium/radeon: query the CPU accessible size of VRAM Is vram_vis_size > vram_size valid? After some time I get this on r600/Turks XT/6670/2 GB: /opt/mesa> setenv R600_DEBUG info /opt/mesa> glxgears pci_id = 0x6758 family = 45 (AMD

[Mesa-dev] [PATCH] radv: use proper maximum slice for layered view

From: Dave Airlie this fixes deferred shadows with geom shaders enabled. but I think this fix is fine by itself. Signed-off-by: Dave Airlie --- src/amd/vulkan/radv_device.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH V2 06/37] util: add a disk_cache_remove() function

From: Timothy Arceri This will be used to remove cache items created with old versions of Mesa or other invalid cache items from the cache. V2: rename stub function (cache_* funtions were renamed disk_cache_*) in master. --- src/util/disk_cache.c | 22

Re: [Mesa-dev] [PATCH 0/7] i965: Implement EGL_ANDROID_native_fence_sync

On 17-01-23 15:32:32, Chad Versace wrote: On Fri 20 Jan 2017, Rafael Antognolli wrote: I have tested this series with the branches that you mentioned, and with piglit with the patches from my own branch: https://github.com/rantogno/piglit/tree/review/fences-v02 Everything seems to work fine.

[Mesa-dev] [PATCH V2 08/37] glsl: add initial implementation of shader cache

From: Timothy Arceri This uses disk_cache.c to write out a serialization of various state that's required in order to successfully load and use a binary written out by a drivers backend, this state is referred to as "metadata" throughout the implementation. This

Re: [Mesa-dev] [PATCH] gallium/radeon: add a new HUD query for the number of mapped buffers

On 26/01/17 08:07 PM, Christian König wrote: > Am 26.01.2017 um 12:01 schrieb Samuel Pitoiset: >> On 01/26/2017 03:45 AM, Michel Dänzer wrote: >>> On 25/01/17 11:19 PM, Samuel Pitoiset wrote: >>> I would like to approach the problem by reducing the amount of vram needed by the userspace

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

Hi Christian, 2017-01-26 12:00 GMT+01:00 Christian König : > Hi Peter, > > Am 25.01.2017 um 19:45 schrieb Peter Frühberger: > >> >> >> Peter, Rainer any idea what I'm missing here? Do you guys use some >> modified ffmpeg for Kodi or how does that work for you? >>

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

2017-01-26 16:36 GMT+01:00 Christian König : > Am 26.01.2017 um 12:16 schrieb Peter Frühberger: > > Hi Christian, > > 2017-01-26 12:00 GMT+01:00 Christian König : > >> Hi Peter, >> >> Am 25.01.2017 um 19:45 schrieb Peter Frühberger: >> >>> >>> >>>

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

Hi Christian, 2017-01-26 19:34 GMT+01:00 Christian König : > Am 26.01.2017 um 16:59 schrieb Peter Frühberger: > > > > 2017-01-26 16:36 GMT+01:00 Christian König : > >> Am 26.01.2017 um 12:16 schrieb Peter Frühberger: >> >> Hi Christian, >> >>

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

Andy Furniss wrote: Andy Furniss wrote: Christian König wrote: Hi guys, ok this is completely work in progress and untested except for a compile run. Most of the stuff necessary should be there for VDPAU, but I'm honestly not sure how to approach VAAPI. These regress R9 285 8bit h264 vaapi

Re: [Mesa-dev] [Intel-gfx] [PATCH] i965: Share the workaround bo between all contexts

On Thu 26 Jan 2017, Chad Versace wrote: > On Thu 26 Jan 2017, Chris Wilson wrote: > > Since the workaround bo is used strictly as a write-only buffer, we need > > only allocate one per screen and use the same one from all contexts. > > > > (The caveat here is during extension initialisation,

[Mesa-dev] [PATCH] winsys/amdgpu: add a fast exit path into amdgpu_cs_add_buffer

From: Marek Olšák The time spent in the function dropped by 37% for torcs. --- src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 16 src/gallium/winsys/amdgpu/drm/amdgpu_cs.h | 5 + 2 files changed, 21 insertions(+) diff --git

[Mesa-dev] [RFC PATCH] gallium: add a common uploader to pipe_context

From: Marek Olšák For lower memory usage and more efficient updates of the buffer residency list. (e.g. if drivers keep seeing the same buffer for many consecutive "add" calls, the calls can be turned into no-ops trivially) --- src/gallium/include/pipe/p_context.h | 7

Re: [Mesa-dev] [Intel-gfx] [PATCH] i965: Share the workaround bo between all contexts

On Thu 26 Jan 2017, Chris Wilson wrote: > On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote: > > On Thu 26 Jan 2017, Chris Wilson wrote: > > > Since the workaround bo is used strictly as a write-only buffer, we need > > > only allocate one per screen and use the same one from all

Re: [Mesa-dev] [PATCH 1/3] [v3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

Sorry, ignore this. I sent to the wrong list. On 17-01-26 14:16:23, Ben Widawsky wrote: Originally based off of a patch by Kristian. This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information about the modifiers that will work with each format. It's modified from Kristian's

[Mesa-dev] [PATCHv2 6/8] nir/spirv/glsl450: Rewrite atan2 implementation to fix accuracy and handling of zero/infinity.

See "glsl: Rewrite atan2 implementation to fix accuracy and handling of zero/infinity." for the rationale, but note that the instruction count benefit discussed there is somewhat less important for the SPIRV implementation, because the current code already emitted no control flow instructions --

[Mesa-dev] [PATCHv2 5/8] glsl: Rewrite atan2 implementation to fix accuracy and handling of zero/infinity.

This addresses several issues of the current atan2 implementation: - Negative zero (and negative denorms which end up getting flushed to zero) isn't handled correctly by the current implementation. The reason is that it does 'y >= 0' and 'x < 0' comparisons to decide on which side of

Re: [Mesa-dev] Build failure of Gallium OSMesa without LLVM

Hey Matt, yeah sorry about this, it is a known problem: https://bugs.freedesktop.org/show_bug.cgi?id=99010 A fix was commited but broke scons and Jose reverted it and doesn't accept the way it was fixed in general. See discussion here:

Re: [Mesa-dev] [PATCH 2/8] glsl: Fix constant evaluation of the rcp op.

Ian Romanick writes: > On 01/26/2017 12:20 PM, Francisco Jerez wrote: >> Ian Romanick writes: >> >>> On 01/25/2017 10:53 AM, Francisco Jerez wrote: Hi Ian, and thank you for your comments, Ian Romanick writes:

[Mesa-dev] [PATCH 1/3] [v3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

Originally based off of a patch by Kristian. This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information about the modifiers that will work with each format. It's modified from Kristian's patch in that the modifiers and formats are setup by the driver, and then a callback is used to

Re: [Mesa-dev] [PATCH 2/8] glsl: Fix constant evaluation of the rcp op.

On 01/26/2017 12:20 PM, Francisco Jerez wrote: > Ian Romanick writes: > >> On 01/25/2017 10:53 AM, Francisco Jerez wrote: >>> Hi Ian, and thank you for your comments, >>> >>> Ian Romanick writes: >>> On 01/24/2017 03:26 PM, Francisco Jerez wrote:

Re: [Mesa-dev] [PATCH] i965: Unbind deleted shaders from brw_context, fixing malloc heisenbug.

On Thursday, January 26, 2017 12:00:14 PM PST Eric Anholt wrote: > Kenneth Graunke writes: > > > Applications may delete a shader program, create a new one, and bind it > > before the next draw. With terrible luck, malloc may randomly return a > > chunk of memory for the

Re: [Mesa-dev] [PATCH 1/4] gallium: Add integer 64 capability

- Original Message - > From: "Marek Olšák" > To: "Nicolai Hähnle" > Cc: "Ilia Mirkin" , mesa-dev@lists.freedesktop.org, > "Dave Airlie" > Sent: Friday, 27 January, 2017 6:18:32 AM > Subject: Re:

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

https://bugs.freedesktop.org/show_bug.cgi?id=97879 matt...@familycampground.org changed: What|Removed |Added CC|

[Mesa-dev] Build failure of Gallium OSMesa without LLVM

Reported against 17.0.0-rc2 [1], but occurs on master as well Reproduce with ./configure --with-dri-drivers= --with-gallium-drivers=swrast --disable-gallium-llvm --enable-gallium-osmesa Fails linking Gallium OSMesa with undefined references to draw_llvm_destroy.

[Mesa-dev] [Bug 95460] Please add more drivers (freedreno, virgl) to features.txt status document

https://bugs.freedesktop.org/show_bug.cgi?id=95460 --- Comment #4 from Shmerl --- FYI: Freedreno is visible in the MesaMatrix: https://mesamatrix.net -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the

Re: [Mesa-dev] [PATCH 7/8] r300: let .get_name() append LLVM if built with LLVM

My preference would be not to use static variables in pipe_screen functions, because all functions needs to be thread-safe, but anyway: Reviewed-by: Marek Olšák Marek On Thu, Jan 26, 2017 at 7:27 PM, Emil Velikov wrote: > From: Emil Velikov

Re: [Mesa-dev] [PATCH 4/4] gallium: enable int64 on radeonsi, llvmpipe, softpipe

For the series: Reviewed-by: Marek Olšák Marek On Thu, Jan 26, 2017 at 8:09 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > All of these have had support for the TGSI opcodes since before most of > the glsl compiler work

Re: [Mesa-dev] [PATCH 01/17] radeonsi: remove si_shader_context::param_tess_offchip

For the series: Tested-by: Edmondo Tommasina Tested with: * The Witcher 2 * Talos Principle * Shadow Tactics * Wasteland 2 * X3: AP * Pillars of Eternity * Uningine Heaven & Valley Thanks edmondo On Thu, Jan 26, 2017 at 5:04 PM, Marek Olšák

Re: [Mesa-dev] [PATCH 2/8] glsl: Fix constant evaluation of the rcp op.

Ian Romanick writes: > On 01/25/2017 10:53 AM, Francisco Jerez wrote: >> Hi Ian, and thank you for your comments, >> >> Ian Romanick writes: >> >>> On 01/24/2017 03:26 PM, Francisco Jerez wrote: Will avoid a regression in a future commit that

Re: [Mesa-dev] [PATCH 1/4] gallium: Add integer 64 capability

On Thu, Jan 26, 2017 at 9:04 PM, Nicolai Hähnle wrote: > On 26.01.2017 20:23, Ilia Mirkin wrote: >> >> I have no serious preference, but for doubles, we use a shader cap. > > > I think this: > >> On Thu, Jan 26, 2017 at 2:09 PM, Nicolai Hähnle >> wrote:

Re: [Mesa-dev] [PATCH 3/8] softpipe: set softpipe_screen::use_llvm when draw is build with LLVM

Am 26.01.2017 um 19:27 schrieb Emil Velikov: > From: Emil Velikov > > Currently we can build draw without LLVM thus honouring SOFTPIPE_USE_LLVM > is misleading even if most of the code nicely falls-back to no-op in the > lack of LLVM. > > That does not seem to be the

Re: [Mesa-dev] [PATCH 1/4] gallium: Add integer 64 capability

Am 26.01.2017 um 21:11 schrieb Ilia Mirkin: > On Thu, Jan 26, 2017 at 3:04 PM, Nicolai Hähnle wrote: >> On 26.01.2017 20:23, Ilia Mirkin wrote: >>> >>> I have no serious preference, but for doubles, we use a shader cap. >> >> >> I think this: >> >>> On Thu, Jan 26, 2017 at

Re: [Mesa-dev] [PATCH 1/4] gallium: Add integer 64 capability

On Thu, Jan 26, 2017 at 3:04 PM, Nicolai Hähnle wrote: > On 26.01.2017 20:23, Ilia Mirkin wrote: >> >> I have no serious preference, but for doubles, we use a shader cap. > > > I think this: > >> On Thu, Jan 26, 2017 at 2:09 PM, Nicolai Hähnle >> wrote:

Re: [Mesa-dev] [PATCH] docs/releasing: add a note about the relnotes template

On 26.01.2017 20:26, Emil Velikov wrote: From: Emil Velikov Signed-off-by: Emil Velikov --- I forget this a bit too often :-\ :D Reviewed-by: Nicolai Hähnle --- docs/releasing.html | 2 ++ 1 file changed,

Re: [Mesa-dev] [PATCH 2/4] st/glsl_to_tgsi: add support for 64-bit integers

On 26.01.2017 20:20, Ilia Mirkin wrote: On Thu, Jan 26, 2017 at 2:09 PM, Nicolai Hähnle wrote: + case ir_unop_i642b: + emit_asm(ir, TGSI_OPCODE_U64SNE, result_dst, op[0], st_src_reg_for_int(0)); + break; Does this work reliably? I would have imagined you'd

Re: [Mesa-dev] [PATCH 1/4] gallium: Add integer 64 capability

On 26.01.2017 20:23, Ilia Mirkin wrote: I have no serious preference, but for doubles, we use a shader cap. I think this: On Thu, Jan 26, 2017 at 2:09 PM, Nicolai Hähnle wrote: v1.1: move to using a normal CAP. (Marek) ... suggests that this has already gone back and

Re: [Mesa-dev] [PATCH] i965: Unbind deleted shaders from brw_context, fixing malloc heisenbug.

Kenneth Graunke writes: > Applications may delete a shader program, create a new one, and bind it > before the next draw. With terrible luck, malloc may randomly return a > chunk of memory for the new gl_program that happened to be the exact > same pointer as our

Re: [Mesa-dev] [PATCH 03/17] gallium/radeon: allow VRAM-only placements again on APUs & recent amdgpu

On Thu, Jan 26, 2017 at 8:43 PM, Ernst Sjöstrand wrote: > Should this code be able to handle drm 4.0.0? DRM 4.0.0 doesn't exist and hopefully won't exist. DRM 1.x.0 = intel DRM 2.x.0 = radeon DRM 3.x.0 = amdgpu That's just a coincidence. Marek

[Mesa-dev] [PATCH 1/3] gallium/radeon: rename grbm to mmio in the gpu load path

We also want to monitor other MMIO counters like SRBM_STATUS2 in order to know if SDMA is busy. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/radeon/r600_gpu_load.c| 30 +++ src/gallium/drivers/radeon/r600_pipe_common.h | 35

[Mesa-dev] [PATCH 3/3] gallium/radeon: add new HUD queries for monitoring the CP

There are even more counters in the CP_STAT register but I think these ones are enough for now. Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/radeon/r600_gpu_load.c| 34 +++ src/gallium/drivers/radeon/r600_pipe_common.h | 9

[Mesa-dev] [PATCH 2/3] gallium/radeon: add new GPU-sdma-busy HUD query

Signed-off-by: Samuel Pitoiset --- src/gallium/drivers/radeon/r600_gpu_load.c| 11 +++ src/gallium/drivers/radeon/r600_pipe_common.h | 3 +++ src/gallium/drivers/radeon/r600_query.c | 5 - src/gallium/drivers/radeon/r600_query.h | 1 + 4

Re: [Mesa-dev] [PATCH 8/8] nouveau: let .get_name() append LLVM if built with LLVM

Yeah, I'd much prefer this to be if (nouveau_screen(pscreen)->class_3d < NV50_3D_CLASS) llvm = " LLVM"; or something along those lines. [Using dev->chipset will be annoying since nv50 = 0x50, and nv67 (nv4x) = 0x67.] On Thu, Jan 26, 2017 at 1:27 PM, Emil Velikov

[Mesa-dev] [Bug 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

https://bugs.freedesktop.org/show_bug.cgi?id=97250 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced

Re: [Mesa-dev] [PATCH 03/17] gallium/radeon: allow VRAM-only placements again on APUs & recent amdgpu

Should this code be able to handle drm 4.0.0? 2017-01-26 17:04 GMT+01:00 Marek Olšák : > From: Marek Olšák > > --- > src/gallium/drivers/radeon/r600_buffer_common.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [Mesa-dev] [PATCH 0/8] LLVM requirement for drivers using draw

On Thu, Jan 26, 2017 at 7:58 PM, Emil Velikov wrote: > On 26 January 2017 at 18:54, Marek Olšák wrote: >> They still have to ship LLVM to have GCN support. Or do they simply not ship >> radeonsi? >> > The latter - they omit anything that requires LLVM.

[Mesa-dev] [PATCH] docs/releasing: add a note about the relnotes template

From: Emil Velikov Signed-off-by: Emil Velikov --- I forget this a bit too often :-\ --- docs/releasing.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/releasing.html b/docs/releasing.html index 2ed66a13f4..020f3dec70

Re: [Mesa-dev] [PATCH 1/4] gallium: Add integer 64 capability

I have no serious preference, but for doubles, we use a shader cap. On Thu, Jan 26, 2017 at 2:09 PM, Nicolai Hähnle wrote: > From: Dave Airlie > > v1.1: move to using a normal CAP. (Marek) > > v2: fill in the cap everywhere > > Signed-off-by: Dave Airlie

Re: [Mesa-dev] [PATCH 2/4] st/glsl_to_tgsi: add support for 64-bit integers

On Thu, Jan 26, 2017 at 2:09 PM, Nicolai Hähnle wrote: > + case ir_unop_i642b: > + emit_asm(ir, TGSI_OPCODE_U64SNE, result_dst, op[0], > st_src_reg_for_int(0)); > + break; Does this work reliably? I would have imagined you'd need a st_srg_reg_for_int64()

[Mesa-dev] [PATCH 1/4] gallium: Add integer 64 capability

From: Dave Airlie v1.1: move to using a normal CAP. (Marek) v2: fill in the cap everywhere Signed-off-by: Dave Airlie Reviewed-by: Marek Olšák (v1) --- src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +

[Mesa-dev] [PATCH 4/4] gallium: enable int64 on radeonsi, llvmpipe, softpipe

From: Nicolai Hähnle All of these have had support for the TGSI opcodes since before most of the glsl compiler work landed. Also update the docs accordingly, including the missing note about i965. --- docs/features.txt| 2 +-

[Mesa-dev] [PATCH 0/4] ARB_gpu_shader_int64 for radeonsi and soft/llvmpipe

Hi all, now that the GLSL compiler work has landed recently, and TGSI has actually had the opcodes for several months, it's time to finally flip the switch! The bulk of the work here is actually due to Dave, with some cleanups from Ian, so kudos to them. I just filled in some minor bits and

[Mesa-dev] [PATCH 2/4] st/glsl_to_tgsi: add support for 64-bit integers

From: Dave Airlie v2: add conversion opcodes. v3 (idr): Rebase on replacemtn of TGSI_OPCODE_I2U64 with TGSI_OPCODE_I2I64. v4 (idr): "cut them down later" => Remove ir_unop_b2u64 and ir_unop_u642b. Handle these with extra i2u or u2i casts just like uint(bool) and bool(uint)

[Mesa-dev] [PATCH 3/4] st/mesa: add support for enabling ARB_gpu_shader_int64.

From: Dave Airlie Signed-off-by: Dave Airlie Reviewed-by: Nicolai Hähnle --- src/mesa/state_tracker/st_extensions.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/state_tracker/st_extensions.c

Re: [Mesa-dev] [PATCH 2/8] glsl: Fix constant evaluation of the rcp op.

On 01/25/2017 10:53 AM, Francisco Jerez wrote: > Hi Ian, and thank you for your comments, > > Ian Romanick writes: > >> On 01/24/2017 03:26 PM, Francisco Jerez wrote: >>> Will avoid a regression in a future commit that introduces some >>> additional rcp operations. >> >>

Re: [Mesa-dev] [PATCH] configure.ac: move require_dri_shared_libs_and_glapi() before its users

On 26 January 2017 at 18:48, Matt Turner wrote: > I ran into this with mesa-17.0.0_rc2. This patch should go into the 17.0 > branch. Seem like I forgot to run ./bin/get-extra-pick-list.sh which flags it up. Thanks Matt, will ensure it's in for rc3. Emil

Re: [Mesa-dev] [PATCH 0/8] LLVM requirement for drivers using draw

On 26 January 2017 at 18:54, Marek Olšák wrote: > They still have to ship LLVM to have GCN support. Or do they simply not ship > radeonsi? > The latter - they omit anything that requires LLVM. I dare not discuss how good/bad/etc of a choice that it, but some people have their

[Mesa-dev] Directly using upstream headers (Was Re: [PATCH] vulkan: Don't install vk_platform.h or vulkan.h.)

On 25 January 2017 at 22:10, Chad Versace wrote: > On Tue 24 Jan 2017, Jason Ekstrand wrote: >> On Tue, Jan 24, 2017 at 11:25 AM, Emil Velikov >> > I'd rather not. That would make sense if we all lived in the >> open-source >> >

Re: [Mesa-dev] [PATCH 0/8] LLVM requirement for drivers using draw

They still have to ship LLVM to have GCN support. Or do they simply not ship radeonsi? Marek On Jan 26, 2017 7:30 PM, "Emil Velikov" wrote: > Hi all, > > Here's a few small fixes/functionality improvements when dealing with > LLVM. > > Most notably the series adds

Re: [Mesa-dev] [PATCH] configure.ac: move require_dri_shared_libs_and_glapi() before its users

I ran into this with mesa-17.0.0_rc2. This patch should go into the 17.0 branch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Share the workaround bo between all contexts

On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote: > On Thu 26 Jan 2017, Chris Wilson wrote: > > Since the workaround bo is used strictly as a write-only buffer, we need > > only allocate one per screen and use the same one from all contexts. > > > > (The caveat here is during

Re: [Mesa-dev] [PATCH 1/8] nir: silence implicit conversion to 64bit

On Thu, Jan 26, 2017 at 10:23 AM, Ian Romanick wrote: > I keep seeing patches like this... is it time to move BITFIELD64_* from > mtypes.h to somewhere in util for more general use? > It may be time > On 01/26/2017 05:18 AM, Emil Velikov wrote: > > From: Emil Velikov

Re: [Mesa-dev] [PATCH 15/17] gallium/radeon: remove r600_common_context::max_db

It should be OK. Marek On Jan 26, 2017 7:17 PM, "Alex Deucher" wrote: > On Thu, Jan 26, 2017 at 12:39 PM, Gustaw Smolarczyk > wrote: > > 2017-01-26 17:04 GMT+01:00 Marek Olšák : > >> From: Marek Olšák > >> >

Re: [Mesa-dev] 10bit HEVC decoding for RadeonSI

Am 26.01.2017 um 16:59 schrieb Peter Frühberger: 2017-01-26 16:36 GMT+01:00 Christian König >: Am 26.01.2017 um 12:16 schrieb Peter Frühberger: Hi Christian, 2017-01-26 12:00 GMT+01:00 Christian König

Re: [Mesa-dev] [PATCH] configure.ac: Require LLVM for r300 only on x86 and x86_64

On 26 January 2017 at 11:13, Andreas Boll wrote: > b3119a3 introduced a strict LLVM requirement for r300 on all > architectures and thus configure fails on architectures where LLVM is > not available or buggy. > > r300 doesn't strictly require LLVM, but for performance

Re: [Mesa-dev] [PATCH mesa] docs/repository: fix name of main branch

On Thu, Jan 26, 2017 at 10:11 AM, Eric Engestrom wrote: > This is git, not svn :P > > Signed-off-by: Eric Engestrom Reviewed-by: Matt Turner > --- > I also noticed some difference between this file and the one on >

Re: [Mesa-dev] [PATCH 2/2] gallium/radeon: add VRAM-vis-usage HUD query

For the series: Reviewed-by: Marek Olšák On Jan 25, 2017 5:50 PM, "Nicolai Hähnle" wrote: Reviewed-by: Nicolai Hähnle On 25.01.2017 16:56, Samuel Pitoiset wrote: > This new query returns the current visible usage of VRAM

Re: [Mesa-dev] [PATCH 1/8] nir: silence implicit conversion to 64bit

On Thu, Jan 26, 2017 at 10:22 AM, Jason Ekstrand wrote: > Ugh... windows defines long to be 32-bit on 32-bit platforms Yeah. long is 32-bit on 32-bit x86/Linux too... I think you mean they define long to be 32-bits on 64-bit platforms.

[Mesa-dev] [PATCH 6/8] i915g: let .get_name() append LLVM if built with LLVM

From: Emil Velikov Provides quick and direct feedback to the user/developer. Cc: Stéphane Marchesin Signed-off-by: Emil Velikov --- src/gallium/drivers/i915/i915_screen.c | 7 ++- 1 file changed, 6

[Mesa-dev] [PATCH 1/8] virgl: remove unused draw_context.h include

From: Emil Velikov Signed-off-by: Emil Velikov --- src/gallium/drivers/virgl/virgl_screen.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/gallium/drivers/virgl/virgl_screen.c b/src/gallium/drivers/virgl/virgl_screen.c index

[Mesa-dev] [PATCH 2/8] llvmpipe: use draw_get_option_use_llvm() instead of open coding it

From: Emil Velikov Cc: Roland Scheidegger Cc: Jose Fonseca Signed-off-by: Emil Velikov --- src/gallium/drivers/llvmpipe/lp_screen.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[Mesa-dev] [PATCH 5/8] i915g: use draw_get_option_use_llvm() instead of open coding it

From: Emil Velikov Currently one can build i915g without LLVM thus the current handling is wrong. Whether using i915g w/o LLVM is a good idea or not is a question for another time. Cc: Stéphane Marchesin Signed-off-by: Emil Velikov

[Mesa-dev] [PATCH 8/8] nouveau: let .get_name() append LLVM if built with LLVM

From: Emil Velikov Analogous to previous two commits. Afaict only nv30 uses draw, so if people prefer we can restrict this print only to those devices. Signed-off-by: Emil Velikov --- Unrelated: Wasn't there a kernel/libdrm helper which

[Mesa-dev] [PATCH 7/8] r300: let .get_name() append LLVM if built with LLVM

From: Emil Velikov Provides quick and direct feedback to the user/developer. Cc: Marek Olšák Signed-off-by: Emil Velikov --- src/gallium/drivers/r300/r300_screen.c | 10 +- 1 file changed, 9 insertions(+), 1

[Mesa-dev] [PATCH 4/8] softpipe: let .get_name() append LLVM if built with LLVM

From: Emil Velikov Provides quick and direct feedback to the user/developer. Cc: Roland Scheidegger Cc: Jose Fonseca Signed-off-by: Emil Velikov --- We can move all the ifdef to a helper, if

[Mesa-dev] [PATCH 3/8] softpipe: set softpipe_screen::use_llvm when draw is build with LLVM

From: Emil Velikov Currently we can build draw without LLVM thus honouring SOFTPIPE_USE_LLVM is misleading even if most of the code nicely falls-back to no-op in the lack of LLVM. That does not seem to be the case in softpipe_draw_vbo() where extra prepare

[Mesa-dev] [PATCH 0/8] LLVM requirement for drivers using draw

Hi all, Here's a few small fixes/functionality improvements when dealing with LLVM. Most notably the series adds "LLVM" string [when applicable] to the .get_name() callback for drivers that use draw. Thus developer can respond accordingly - be that "rebuild with LLVM or enjoy the bad

[Mesa-dev] [PATCH] st/va encode handle ntsc framerate rate control

Tested with ffmpeg and gst-vaapi. Without this bits per frame is set way too low. Signed-off-by: Andy Furniss --- src/gallium/state_trackers/va/picture.c | 32 1 file changed, 24 insertions(+), 8 deletions(-) diff --git

Re: [Mesa-dev] [PATCH 1/8] nir: silence implicit conversion to 64bit

I keep seeing patches like this... is it time to move BITFIELD64_* from mtypes.h to somewhere in util for more general use? On 01/26/2017 05:18 AM, Emil Velikov wrote: > From: Emil Velikov > > MSVC warns about implicit conversion as below. Annotate the literal >

Re: [Mesa-dev] [PATCH 1/8] nir: silence implicit conversion to 64bit

Ugh... windows defines long to be 32-bit on 32-bit platforms Yeah. Reviewed-by: Jason Ekstrand On Thu, Jan 26, 2017 at 6:05 AM, Lionel Landwerlin < lionel.g.landwer...@intel.com> wrote: > Reviewed-by: Lionel Landwerlin > > On 26/01/17

Re: [Mesa-dev] [PATCH 2/8] nir: add extra const notation in compare_blocks()

LGTM On Thu, Jan 26, 2017 at 6:05 AM, Lionel Landwerlin < lionel.g.landwer...@intel.com> wrote: > Reviewed-by: Lionel Landwerlin > > On 26/01/17 13:18, Emil Velikov wrote: > >> From: Emil Velikov >> >> MSVC warns about different const

Re: [Mesa-dev] [PATCH 5/8] glsl: Rewrite atan2 implementation to fix accuracy and handling of zero/infinity.

On 01/25/2017 12:55 PM, Francisco Jerez wrote: > Ian Romanick writes: > >> It's a real bummer that we have two implementations of this function >> that are basically written in assembly... I'm not sure what else you'd >> call generating IR by hand. The code review and

Re: [Mesa-dev] [PATCH 15/17] gallium/radeon: remove r600_common_context::max_db

On Thu, Jan 26, 2017 at 12:39 PM, Gustaw Smolarczyk wrote: > 2017-01-26 17:04 GMT+01:00 Marek Olšák : >> From: Marek Olšák >> >> this cleanup is based on the vulkan driver, which seems to do the same thing > > Is this also ok for

[Mesa-dev] [PATCH mesa] docs/repository: fix name of main branch

This is git, not svn :P Signed-off-by: Eric Engestrom --- I also noticed some difference between this file and the one on mesa3d.org; it might be worth making sure everything is sync'ed between the two (most likely just push the version on git to the webserver). ---

Re: [Mesa-dev] [PATCH] clover: Fix build against clang SVN >= r293097

Michel Dänzer writes: > From: Michel Dänzer > > Signed-off-by: Michel Dänzer Reviewed-by: Francisco Jerez > --- > > Not sure if PropagateAttrs should be set to true or false. Setting it to > true

Re: [Mesa-dev] [PATCH] i965: Share the workaround bo between all contexts

On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote: > On Thu 26 Jan 2017, Chris Wilson wrote: > > Since the workaround bo is used strictly as a write-only buffer, we need > > only allocate one per screen and use the same one from all contexts. > > > > (The caveat here is during

Re: [Mesa-dev] [PATCH 4/8] i965/fs: Fix nir_op_fsign of absolute value.

On 01/25/2017 01:42 PM, Francisco Jerez wrote: > Ian Romanick writes: > >> On 01/24/2017 03:26 PM, Francisco Jerez wrote: >>> This does point at the front-end emitting silly code that could have >>> been optimized out, but the current fsign implementation would emit >>>

Re: [Mesa-dev] [PATCH 7/8] st/mesa: explicitly handle/list 64bit ops in visit_expression()

Reviewed-by: Marek Olšák On Jan 26, 2017 2:22 PM, "Emil Velikov" wrote: > From: Emil Velikov > > Follow the approach set in the file and handle all the ops, as otherwise > the compiler throws a bunch of lovely

Re: [Mesa-dev] [PATCH 5/8] st/mesa: use correct return statement for a void function

Reviewed-by: Marek Olšák On Jan 26, 2017 2:21 PM, "Emil Velikov" wrote: > From: Emil Velikov > > Analogous to previous commit. > > Signed-off-by: Emil Velikov > --- >

Re: [Mesa-dev] [PATCH] configure.ac: Require LLVM for r300 only on x86 and x86_64

Reviewed-by: Marek Olšák On Jan 26, 2017 12:13 PM, "Andreas Boll" wrote: > b3119a3 introduced a strict LLVM requirement for r300 on all > architectures and thus configure fails on architectures where LLVM is > not available or buggy. > > r300

  1   2   >