Ouch...
Reviewed-by: Jason Ekstrand
On Wed, Jan 25, 2017 at 11:14 PM, Kenneth Graunke
wrote:
> 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 happene
On Wed, Jan 25, 2017 at 11:14:32PM -0800, Kenneth Graunke wrote:
> 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
On Tue, Jan 24, 2017 at 03:45:49PM -0800, Jason Ekstrand wrote:
> This commit adds support for using both R24_UNORM_X8_TYPELESS and
> R9G9B9E5_SHAREDEXP as destination formats even though the hardware does
> not support rendering to them. This is done by using a different format
> and emitting sha
On Tue, Jan 24, 2017 at 03:45:54PM -0800, Jason Ekstrand wrote:
> Previously, blorp could only blit into something that was renderable.
> Thanks to recent additions to blorp, it can now blit into basically
> anything so long as it isn't compressed.
> ---
> src/mesa/drivers/dri/i965/brw_blorp.c | 6
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 previously bound gl_program. In this case, our
logic to detect ne
On Tue, Jan 24, 2017 at 03:45:51PM -0800, Jason Ekstrand wrote:
> ---
> src/intel/blorp/blorp_blit.c | 4
> 1 file changed, 4 insertions(+)
Patches 3 and 4 are:
Reviewed-by: Topi Pohjolainen
Patch 2 looks good also. I just need to study the E9-math some more. Although
I may not be the bes
On Wed, Jan 25, 2017 at 10:51:53PM -0800, Jason Ekstrand wrote:
>On Wed, Jan 25, 2017 at 10:46 PM, Pohjolainen, Topi
><[1]topi.pohjolai...@gmail.com> wrote:
>
>On Tue, Jan 24, 2017 at 03:45:48PM -0800, Jason Ekstrand wrote:
>> The previous version was sort-of strapped on in that it
On Wed, Jan 25, 2017 at 10:46 PM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Tue, Jan 24, 2017 at 03:45:48PM -0800, Jason Ekstrand wrote:
> > The previous version was sort-of strapped on in that it just adjusted
> > the blit rectangle and trusted in the fact that we would use texe
On Tue, Jan 24, 2017 at 03:45:48PM -0800, Jason Ekstrand wrote:
> The previous version was sort-of strapped on in that it just adjusted
> the blit rectangle and trusted in the fact that we would use texelFetch
> and round to the nearest integer to ensure that the component positions
> matched. Thi
When a texture is immutable, we can't tack on extra levels
after-the-fact like we could with glTexImage. So check against that
level limit and return an error if it's surpassed.
The spec is a little unclear in that it says to check if "level is not a
supported texture level", however that is never
All the other calls to retrieve the attachment have been covered except
this one - return the proper error for attachment points that are valid
enums but out of bound for the driver.
Fixes GL45-CTS.geometry_shader.layered_fbo.fb_texture_invalid_attachment
Signed-off-by: Ilia Mirkin
---
v1 -> v2
On Wed, Jan 25, 2017 at 11:51 PM, Ilia Mirkin wrote:
> Kepler and up unfortunately only support up to 8 constbufs. We work
> around this by loading from constbufs as if they were storage buffers.
> However we were not consistently applying limits to loads from these
> buffers. Make sure to do the
Kepler and up unfortunately only support up to 8 constbufs. We work
around this by loading from constbufs as if they were storage buffers.
However we were not consistently applying limits to loads from these
buffers. Make sure to do the same thing we do for storage buffers.
Fixes GL45-CTS.robust_b
https://bugs.freedesktop.org/show_bug.cgi?id=97967
--- Comment #10 from Vinson Lee ---
Can someone provide a patch with the print statements wanted to test?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #58 from Vladislav Egorov ---
Correction - in fact I only tested radeon+radeonsi pair. I will try
amdgpu+radeonsi later.
--
You are receiving this mail because:
You are the assignee for the bug.__
Apparently GL 4.5 requires 14 of these (there's a "*" in the spec, but
it's unclear what it refers to). We need to expose an extra binding
point for the "program parameters", which means this must be 15. Remove
the last vestige of the "use c14 for immediates" idea.
Fixes GL45-CTS.shading_language_
This fixes
GL45-CTS.tessellation_shader.tessellation_shader_tessellation.max_in_out_attributes
likely among others on nouveau. We only support 30 patch varyings (as 2
vec4 slots end up being used for tess level settings), but were getting
32 exposed.
Signed-off-by: Ilia Mirkin
---
src/mesa/state
Many many many compute shaders only define a 1- or 2-dimensional block,
but then continue to use system values that take the full 3d into
account (like gl_LocalInvocationIndex, etc). So for the special case
that a dimension is exactly 1, we know that the thread id along that
axis will always be 0,
We are casting from a signed 32bit int to an unsigned 16bit int
so shift 15 bits rather than 16.
---
src/mesa/drivers/dri/i965/brw_inst.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_inst.h
b/src/mesa/drivers/dri/i965/brw_inst.h
index 13fce
jip should always be negative here as its the result of
do instruction - while instruction.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 257757f..f4bec33 1006
On 25/01/17 11:19 PM, Samuel Pitoiset wrote:
> On 01/25/2017 03:56 AM, Michel Dänzer wrote:
>> On 25/01/17 12:05 AM, Marek Olšák wrote:
>>> On Tue, Jan 24, 2017 at 2:17 PM, Christian König
>>> wrote:
Am 24.01.2017 um 11:44 schrieb Samuel Pitoiset:
> On 01/24/2017 11:38 AM, Nicolai Hähnle
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #57 from Vladislav Egorov ---
Simple way to reproduce the bug - launch the game, then go to "Options" menu
and get multi-second (>5s) freeze.
I've tried to launch Rocket League on several GPUs. Graphics settings were the
same everywh
Hi Christian,
2017-01-25 15:41 GMT+01:00 Christian König :
> 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.
>
> My main problem at the moment
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 decode with mpv,
[vd] Pixel formats supp
Signed-off-by: Bas Nieuwenhuizen
Tested-by: Andres Rodriguez
---
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 f56f67c400e..c968cefc9c7 100644
--- a/src/amd/vulkan/radv_formats.c
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 b/src/amd/vulkan/radv_formats.c
index e276432c2ee..f56f67c400e 100644
--- a/s
On Wed 25 Jan 2017, Jason Ekstrand wrote:
>
>
> On Wed, Jan 25, 2017 at 12:12 PM, Chad Versace
> wrote:
>
> +VkResult vkGetPhysicalDeviceImageFormatProperties2KHR(
>
>
> This needs to be anv_
Oops.
___
mesa-dev mailing list
mesa-dev@lists.free
Series Reviewed-by: Jordan Justen
On 2017-01-24 17:30:11, Ian Romanick wrote:
> These are some patches that I wrote ages ago... the initial versions
> pre-date Mesa's ARB_gpu_shader_fp64 support. This was part of a larger
> effort that got bogged down and eventually abandonded. The problem with
On Wed, Jan 25, 2017 at 12:12 PM, Chad Versace
wrote:
> ---
> src/intel/vulkan/anv_device.c | 90 ++
>
> src/intel/vulkan/anv_formats.c | 53 +
> src/intel/vulkan/anv_private.h | 18 +
> 3 files changed, 161 insertions(+)
On Wed 25 Jan 2017, Lionel Landwerlin wrote:
> Looks good to me :
>
> Reviewed-by: Lionel Landwerlin
>
> On 25/01/17 20:12, Chad Versace wrote:
> > Untested, but builds. I wanted to get feedback on this approach before
> > going through the trouble of fetching and building the newest CTS. If
> >
Looks good to me :
Reviewed-by: Lionel Landwerlin
On 25/01/17 20:12, Chad Versace wrote:
Untested, but builds. I wanted to get feedback on this approach before
going through the trouble of fetching and building the newest CTS. If
the review feedback is good, then I'll test it with the CTS.
Y
On Tue 24 Jan 2017, Jason Ekstrand wrote:
> On Tue, Jan 24, 2017 at 11:25 AM, Emil Velikov
> wrote:
>
> On 24 January 2017 at 18:02, Jason Ekstrand wrote:
> > On Tue, Jan 24, 2017 at 9:03 AM, Matt Turner wrote:
> >>
> >> On Tue, Jan 24, 2017 at 8:41 AM, Emil Velikov
>
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=97879
Clément Guérin changed:
What|Removed |Added
CC||geecko@free.fr
--
You are receivin
Having read through this code, I think I like this approach. It seems to
be the most easily extensible thing we can do. Series is
Reviewed-by: Jason Ekstrand
On Wed, Jan 25, 2017 at 12:12 PM, Chad Versace
wrote:
> ---
> src/intel/vulkan/anv_device.c | 90 ++
> ++
On Tue 24 Jan 2017, Eric Engestrom wrote:
> Khronos introduced a new macro (suggested by Google) to avoid using
> C-style casts in C++ code, as those generate warnings.
>
> Khronos Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16113
> Signed-off-by: Eric Engestrom
> ---
> include/EG
On Wed 25 Jan 2017, Lionel Landwerlin wrote:
> The spec section 5.2 says:
>
>"vkAllocateCommandBuffers can be used to create multiple command
>buffers. If the creation of any of those command buffers fails, the
>implementation must destroy all successfully created command buffer
>o
The struct was deleted by:
commit efe9d1cde3340d3a9d17e5560b609a4fb839d43d
Author: Edward O'Callaghan
Subject: anv: Clean up some unused variables
Unlike the original anv_common, the new one has a non-const pNext
pointer because we will use it for the output structs of
VK_KHR_get_physical_d
On Wed 25 Jan 2017, Jason Ekstrand wrote:
> On Wed, Jan 25, 2017 at 12:12 PM, Chad Versace
> wrote:
>
> The struct was deleted by:
> commit efe9d1cde3340d3a9d17e5560b609a4fb839d43d
> Author: Edward O'Callaghan
> Subject: anv: Clean up some unused variables
>
> Unlike t
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
>> bogus IR if abs was set for the argument (because it would apply the
>> abs modif
On Wed, Jan 25, 2017 at 12:12 PM, Chad Versace
wrote:
> The struct was deleted by:
> commit efe9d1cde3340d3a9d17e5560b609a4fb839d43d
> Author: Edward O'Callaghan
> Subject: anv: Clean up some unused variables
>
> Unlike the original anv_common, the new one has a non-const pNext
> pointer b
On Wed, Jan 25, 2017 at 1:25 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Yes, we have VkPhysicalDeviceFeatures.multiDrawIndirect disabled for now.
> I was going to look at that in another series, given that this one didn't
> break anything in the CI.
>
Right. That means that
Yes, we have VkPhysicalDeviceFeatures.multiDrawIndirect disabled for now.
I was going to look at that in another series, given that this one
didn't break anything in the CI.
-
Lionel
On 25/01/17 19:21, Jason Ekstrand wrote:
Is there something we need to do here to plumb gl_DrawId through
corr
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 maintenance costs are
> of the same magnitude for sure.
>
> We could move this to
This is a printf-like macro that prints a debug message to stderr when
built with DEBUG. If no DEBUG, then do nothing.
---
src/intel/vulkan/anv_private.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 75f2bde66a..de50dff
---
src/intel/vulkan/anv_device.c | 90 ++
src/intel/vulkan/anv_formats.c | 53 +
src/intel/vulkan/anv_private.h | 18 +
3 files changed, 161 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_de
Add a helper function, anv_get_image_format_properties(), which does all
the work and has a VkPhysicalDeviceImageFormatInfo2KHR parameter. This
patch reduces churn in the following patch that implements
vkGetPhysicalDeviceImageFormatProperties2KHR.
---
src/intel/vulkan/anv_formats.c | 77 +
The struct was deleted by:
commit efe9d1cde3340d3a9d17e5560b609a4fb839d43d
Author: Edward O'Callaghan
Subject: anv: Clean up some unused variables
Unlike the original anv_common, the new one has a non-const pNext
pointer because we will use it for the output structs of
VK_KHR_get_physical_d
Add a helper function, anv_get_queue_family_properties(), which fills the
struct. This patch reduces churn in the following patch that implements
vkGetPhysicalDeviceQueueFamilyProperties2KHR.
---
src/intel/vulkan/anv_device.c | 26 +-
1 file changed, 17 insertions(+), 9 de
Untested, but builds. I wanted to get feedback on this approach before
going through the trouble of fetching and building the newest CTS. If
the review feedback is good, then I'll test it with the CTS.
Pushed as tag 'chadv/review/anv-VK_KHR_get_physical_device_properties2-v02'
in my repo:
http
On Tue 24 Jan 2017, Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/vulkan/anv_device.c | 593
> +
> src/intel/vulkan/anv_formats.c | 42 +++
> 2 files changed, 398 insertions(+), 237 deletions(-)
> +static void
> +anv_phy
https://bugs.freedesktop.org/show_bug.cgi?id=93375
Vedran Miletić changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |ved...@miletic.net
|o
https://bugs.freedesktop.org/show_bug.cgi?id=93375
Vedran Miletić changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Jan 23, 2017 at 4:54 PM, Matt Turner wrote:
> These files belong to the vulkan loader.
I forgot to add the tag, but this (commit 045f38a5075) should go to
the 17.0 branch. Emil, can you see to that?
___
mesa-dev mailing list
mesa-dev@lists.freed
Is there something we need to do here to plumb gl_DrawId through
correctly? I'm pretty sure we have exactly zero code for that.
On Wed, Jan 25, 2017 at 10:55 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Enables 10 tests from:
>
>dEQP-VK.draw.shader_draw_parameters.*
>
> Si
On Wed, Jan 25, 2017 at 09:01:56PM +0200, Pohjolainen, Topi wrote:
> On Mon, Jan 23, 2017 at 10:21:40PM -0800, Ben Widawsky wrote:
> > Previously our aux buffers (MCS, and HiZ) never had an offset because
> > they were in their own buffer object. When using the CCS lossless
> > compression feature,
On Mon, Jan 23, 2017 at 10:21:40PM -0800, Ben Widawsky wrote:
> Previously our aux buffers (MCS, and HiZ) never had an offset because
> they were in their own buffer object. When using the CCS lossless
> compression feature, it's desirable to store the data at an offset from
> the main framebuffer,
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.
>
> When I converted GLSL IR to ir_expression_operation.py, I was careful to
> keep all
On Mon, Jan 23, 2017 at 10:21:41PM -0800, Ben Widawsky wrote:
> This provides a common function or creating miptrees when there is an
> existing DRIimage to use. That provides an easy way to add CCS
> allocation.
>
> Signed-off-by: Ben Widawsky
> Acked-by: Daniel Stone
> ---
> src/mesa/drivers/
Enables 10 tests from:
dEQP-VK.draw.shader_draw_parameters.*
Signed-off-by: Lionel Landwerlin
---
src/intel/vulkan/anv_device.c | 4
src/intel/vulkan/anv_pipeline.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
inde
Signed-off-by: Lionel Landwerlin
---
src/compiler/spirv/nir_spirv.h | 1 +
src/compiler/spirv/spirv_to_nir.c | 4
src/compiler/spirv/vtn_variables.c | 12
3 files changed, 17 insertions(+)
diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
index
Hi,
This extensions is the equivalent of GL_ARB_shader_draw_parameters.
This was added by Vulkan 1.0.39.
Cheers,
Lionel Landwerlin (2):
spirv: add SPV_KHR_shader_draw_parameters support
anv: enable VK_KHR_shader_draw_parameters
src/compiler/spirv/nir_spirv.h | 1 +
src/compiler/spirv/
On Mon, Jan 23, 2017 at 10:21:42PM -0800, Ben Widawsky wrote:
> This code will disable actually creating these buffers for the scanout,
> but it puts the allocation in place.
>
> Primarily this patch is split out for review, it can be squashed in
> later if preferred.
>
> v2:
> assert(mt->offset
On Mon, Jan 23, 2017 at 10:21:43PM -0800, Ben Widawsky wrote:
> Make the code only disable CCS when it has to, unlike before where it
> disabled CCS and enabled it when it could. This is much more inline with
> how it should work in a few patches, where we have fewer restrictions as
> to when we di
On Mon, Jan 23, 2017 at 10:21:56PM -0800, Ben Widawsky wrote:
> v2: Try to keep the assert as recommended by Topi. This requires
> modifying the num_samples check to be <= 1 because internally created
> buffers set num_samples = 0.
>
> v3: Buffers are proactively marked as scanout, often, and so c
On Mon, Jan 23, 2017 at 10:21:55PM -0800, Ben Widawsky wrote:
> We no longer allocate a miptree for the mcs_buf, so this is not a useful
> assertion.
>
> While here, move the CCS disabling so that we only conditionally shut it
> off. This helps us dtrt later when CCS is used in more places.
>
> R
On Mon, Jan 23, 2017 at 10:21:54PM -0800, Ben Widawsky wrote:
> On Gen9 hardware, the display engine is able to scanout a compressed
> framebuffer by providing an offset to auxiliary compression information.
> Unfortunately, the hardware is incapable of doing the same thing for the
> fast clear col
On Mon, Jan 23, 2017 at 10:21:46PM -0800, Ben Widawsky wrote:
> This patch provides the support (and comments) for allocating the BO
> with space for the CCS buffer just underneath it.
>
> This patch was originally titled:
> "i965: Create correctly sized mcs for an image"
>
> In order to make thi
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #56 from Grazvydas Ignotas ---
Is the async I/O thread doing a lot of memory allocations?
If so, perhaps the malloc implementation is slowed down by having large amount
of small allocs/frees from shader compiles and/or fragmentation
On Wed, Jan 25, 2017 at 4:45 AM, Bas Nieuwenhuizen
wrote:
> Can you split the switch changes to a different commit? With that,
>
Agreed,
Reviewed-by: Jason Ekstrand
> Reviewed-by: Bas Nieuwenhuizen
>
> for the series.
>
> On Wed, Jan 25, 2017, at 04:39, Lionel Landwerlin wrote:
> > Signed-o
Oops...
Reviewed-by: Jason Ekstrand
Cc: "17.0"
On Wed, Jan 25, 2017 at 7:28 AM, Iago Toral Quiroga
wrote:
> According to GL_KHR_vulkan_glsl, the signature of subpassLoad() is:
>
> gvec4 subpassLoad(gsubpassInput subpass);
> gvec4 subpassLoad(gsubpassInputMS subpass, int sample);
>
> So the
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #55 from Timothee Besset ---
Rocket League uses an async I/O thread to stream in content in the background.
That thread works off of a queue and only does disk reads and decompression (it
doesn't issue any OpenGL calls for instance, t
I thought I looked for this when doing maintenance1... oh well.
Reviewed-by: Jason Ekstrand
Cc: "13.0 17.0"
On Wed, Jan 25, 2017 at 8:29 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> The spec section 5.2 says:
>
>"vkAllocateCommandBuffers can be used to create multiple co
On Wed, Jan 25, 2017 at 8:29 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> The spec section 5.2 says:
>
>"vkAllocateCommandBuffers can be used to create multiple command
>buffers. If the creation of any of those command buffers fails, the
>implementation must destroy
mesa 17.0 is scheduled to be released earlier than llvm-4.0, so imho no,
not worth the effort.
I certainly won't stop anyone from porting the necessary changes and
doing some minimal testing, though...
Roland
Am 25.01.2017 um 17:47 schrieb Nicolai Hähnle:
> I think we can consider it, but note th
Reviewed-by: Nicolai Hähnle
On 25.01.2017 16:56, Samuel Pitoiset wrote:
This new query returns the current visible usage of VRAM accessed
by the CPU. It will return 0 on radeon because it's unimplemented.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/radeon/r600_query.c |
I think we can consider it, but note that it's not entirely trivial. In
addition to compile fixes, there were changes in intrinsics that are
relevant for radeonsi.
Nicolai
On 25.01.2017 17:19, Matt Turner wrote:
To make distributions lives easier, can we please support llvm-4.0 in
the mesa-13
The spec section 5.2 says:
"vkAllocateCommandBuffers can be used to create multiple command
buffers. If the creation of any of those command buffers fails, the
implementation must destroy all successfully created command buffer
objects from this command, set all entries of the pCommand
To make distributions lives easier, can we please support llvm-4.0 in
the mesa-13.0 branch?
It currently fails to compile:
https://bugs.gentoo.org/show_bug.cgi?id=606608
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.o
On 01/25/2017 05:05 PM, Christian König wrote:
Am 25.01.2017 um 16:12 schrieb Samuel Pitoiset:
On 01/25/2017 04:01 PM, Samuel Pitoiset wrote:
On 01/25/2017 03:55 PM, Christian König wrote:
Am 25.01.2017 um 15:19 schrieb Samuel Pitoiset:
On 01/25/2017 03:56 AM, Michel Dänzer wrote:
On
This new query returns the current visible usage of VRAM accessed
by the CPU. It will return 0 on radeon because it's unimplemented.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/radeon/r600_query.c | 7 +++
src/gallium/drivers/radeon/r600_query.h | 1 +
src/gall
Am 25.01.2017 um 16:12 schrieb Samuel Pitoiset:
On 01/25/2017 04:01 PM, Samuel Pitoiset wrote:
On 01/25/2017 03:55 PM, Christian König wrote:
Am 25.01.2017 um 15:19 schrieb Samuel Pitoiset:
On 01/25/2017 03:56 AM, Michel Dänzer wrote:
On 25/01/17 12:05 AM, Marek Olšák wrote:
On Tue, Ja
On 24 January 2017 at 18:07, Eric Engestrom wrote:
> Khronos introduced a new macro (suggested by Google) to avoid using
> C-style casts in C++ code, as those generate warnings.
>
> Khronos Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16113
> Signed-off-by: Eric Engestrom
> ---
> i
https://bugs.freedesktop.org/show_bug.cgi?id=98223
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
R600_DEBUG="info" can be used to display that size, as well as
the total amount of VRAM/GTT.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/radeon_winsys.h| 1 +
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c |
According to GL_KHR_vulkan_glsl, the signature of subpassLoad() is:
gvec4 subpassLoad(gsubpassInput subpass);
gvec4 subpassLoad(gsubpassInputMS subpass, int sample);
So the multisampled case always receives an explicit sample index that we
should use. The current implementation was ignoring thi
Am 25.01.2017 um 16:01 schrieb Samuel Pitoiset:
On 01/25/2017 03:55 PM, Christian König wrote:
Am 25.01.2017 um 15:19 schrieb Samuel Pitoiset:
On 01/25/2017 03:56 AM, Michel Dänzer wrote:
On 25/01/17 12:05 AM, Marek Olšák wrote:
On Tue, Jan 24, 2017 at 2:17 PM, Christian König
wrote:
Am
Am 25.01.2017 um 15:19 schrieb Samuel Pitoiset:
On 01/25/2017 03:56 AM, Michel Dänzer wrote:
On 25/01/17 12:05 AM, Marek Olšák wrote:
On Tue, Jan 24, 2017 at 2:17 PM, Christian König
wrote:
Am 24.01.2017 um 11:44 schrieb Samuel Pitoiset:
On 01/24/2017 11:38 AM, Nicolai Hähnle wrote:
On 24
On 01/25/2017 04:01 PM, Samuel Pitoiset wrote:
On 01/25/2017 03:55 PM, Christian König wrote:
Am 25.01.2017 um 15:19 schrieb Samuel Pitoiset:
On 01/25/2017 03:56 AM, Michel Dänzer wrote:
On 25/01/17 12:05 AM, Marek Olšák wrote:
On Tue, Jan 24, 2017 at 2:17 PM, Christian König
wrote:
A
On 01/25/2017 03:55 PM, Christian König wrote:
Am 25.01.2017 um 15:19 schrieb Samuel Pitoiset:
On 01/25/2017 03:56 AM, Michel Dänzer wrote:
On 25/01/17 12:05 AM, Marek Olšák wrote:
On Tue, Jan 24, 2017 at 2:17 PM, Christian König
wrote:
Am 24.01.2017 um 11:44 schrieb Samuel Pitoiset:
On
Hello list,
The candidate for the Mesa 13.0.4 is now available. Currently we have:
- 61 queued
- 18 nominated (outstanding)
- and 2 rejected patch(es)
With this series we have - multiple fixes for the i965 and radeonsi drivers.
An odd glitch in glxgears and freedreno was resolved, with the AN
From: Christian König
Same layout as NV12, but 16bit per channel instead of 8.
Signed-off-by: Christian König
---
src/gallium/auxiliary/util/u_format.csv | 2 ++
src/gallium/auxiliary/util/u_format_yuv.c | 19 +++
src/gallium/auxiliary/util/u_format_yuv.h | 19 ++
From: Christian König
Just simply the description of the planes.
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.
From: Christian König
That allows us to switch between different
surface formats for different codecs.
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/decode.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/d
From: Christian König
Just use whatever the state tracker allocated.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 5 ++---
src/gallium/drivers/radeon/radeon_video.c | 11 ++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/gallium/
From: Christian König
That should make it possible to use the 16bit surfaces in OpenGL as well.
Signed-off-by: Christian König
---
src/gallium/include/state_tracker/vdpau_dmabuf.h | 2 ++
src/gallium/include/state_tracker/vdpau_funcs.h | 4
src/gallium/state_trackers/vdpau/surface.c
From: Christian König
No need to have that twice.
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/surface.c | 52 +
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trac
From: Christian König
Most likely only partially correct, but at least a start.
Signed-off-by: Christian König
---
src/gallium/state_trackers/va/config.c | 9 ++---
src/gallium/state_trackers/va/image.c | 10 ++
src/gallium/state_trackers/va/surface.c| 28
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.
My main problem at the moment is that I can't get mpv/ffmpeg to decode Main10
content using VDPAU and w
On 01/25/2017 03:56 AM, Michel Dänzer wrote:
On 25/01/17 12:05 AM, Marek Olšák wrote:
On Tue, Jan 24, 2017 at 2:17 PM, Christian König
wrote:
Am 24.01.2017 um 11:44 schrieb Samuel Pitoiset:
On 01/24/2017 11:38 AM, Nicolai Hähnle wrote:
On 24.01.2017 11:34, Samuel Pitoiset wrote:
On 01/24/
Series is
Reviewed-by: Bas Nieuwenhuizen
On Wed, Jan 25, 2017, at 06:05, Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> src/compiler/spirv/spirv_to_nir.c | 12
> src/compiler/spirv/vtn_variables.c | 3 +++
> 2 files changed, 15 insertions(+)
>
> diff --git
1 - 100 of 121 matches
Mail list logo
