On 30.10.2015 01:34, Marek Olšák wrote:
> From: Marek Olšák
>
> Untested. I don't have Stoney.
It looks good to me, but can you get it tested by somebody?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X
On 30.10.2015 02:49, Matt Turner wrote:
> On Thu, Oct 29, 2015 at 10:15 AM, Grazvydas Ignotas wrote:
>> Hi,
>>
>> On Thu, Oct 29, 2015 at 6:21 PM, Emil Velikov
>> wrote:
>>> On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
>>> wrote:
This was causing compilation issues when one of its prov
On 30.10.2015 03:08, Marek Olšák wrote:
> From: Marek Olšák
The series is
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
On 30.10.2015 08:11, Nicolai Hähnle wrote:
>
> I am not familiar with patchwork yet and have a related question: on my
> push, I got the following error message related to patchwork:
>
> remote: E: failed to find patch for rev
> f75f21a24ae2dd83507f3d4d8007f0fcfe6db802
>
> Apparently, patchwork
On Oct 29, 2015 5:51 PM, "Matt Turner" wrote:
>
> We've made a mistake in calling the Channel Enable bits "writemask",
> because they do more than control which channels of the destination are
> written -- they actually control which channels are enabled (surprise!
> surprise!)
>
> So, if we emit
It did a bunch of unnecessary stuff, emitting an extra MOV included.
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 7 +++
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 18 +-
2 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir
If we add a new file type, we'd like to get warnings if it's not
handled.
Unfortuately, gcc seems to have bugs (see the XXX).
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 16 +---
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp | 7 ---
src/mesa/drivers/dri/i
We've made a mistake in calling the Channel Enable bits "writemask",
because they do more than control which channels of the destination are
written -- they actually control which channels are enabled (surprise!
surprise!)
So, if we emit
cmp.z.f0(8) null.xy<1>D g10<4,4,1>.xyzzD g2
Like other gen8+ hardware, the hardware automatically scales up thread counts
and URB sizes, so there is no need to do anything but add the PCI IDs.
FINISHME: This patch still needs testing before merge.
v2: Remove the PCI ID removal. That should be done as part of the next patch.
v3: Update the
>
> What exactly are the parameters to glGetTextureSubImage() that hits this?
It's actually a call to glGetnTexImage
#4 0x772ce215 in get_tex_depth (ctx=0x9d03d0, dimensions=2,
xoffset=0, yoffset=0, zoffset=0, width=65, height=1, depth=40,
format=6402, type=5125,
pixels=0xe32a10, tex
On 29 October 2015 at 22:56, Nicolai Hähnle wrote:
> On 29.10.2015 14:13, Marek Olšák wrote:
>>
>> On Wed, Oct 28, 2015 at 1:00 PM, Nicolai Hähnle
>> wrote:
>>>
>>> Without the clamping by NumLevels, the state tracker would reallocate the
>>> texture storage (incorrect) and even fail to copy the
On 29 October 2015 at 23:04, Arnaud Vrac wrote:
> On Thu, Oct 29, 2015 at 11:28 PM, Emil Velikov
> wrote:
>>
>> On 20 October 2015 at 17:40, Arnaud Vrac wrote:
>> > On Tue, Oct 20, 2015 at 6:35 PM, Emil Velikov
>> > wrote:
>> >>
>> >> On 20 October 2015 at 17:06, Julien Isorce
>> >> wrote:
>>
On Thu, Oct 29, 2015 at 4:23 PM, Ilia Mirkin wrote:
> On Thu, Oct 29, 2015 at 7:11 PM, Nicolai Hähnle wrote:
>> perhaps because it
>> wasn't inline. Is this something to worry about? Specifically, I believe the
>> patch is a candidate for the stable branch, and I added the appropriate Cc:
>> in t
On Thu, Oct 29, 2015 at 7:11 PM, Nicolai Hähnle wrote:
> On 29.10.2015 10:24, Ivan Kalvachev wrote:
> [snip]
>>
>> On 10/29/15, Nicolai Hähnle wrote:
>>>
>>> On 29.10.2015 01:52, Ivan Kalvachev wrote:
On 10/26/15, Nicolai Hähnle wrote:
>
> On 25.10.2015 02:00, Ivan Kalvachev wr
On 29.10.2015 10:24, Ivan Kalvachev wrote:
[snip]
On 10/29/15, Nicolai Hähnle wrote:
On 29.10.2015 01:52, Ivan Kalvachev wrote:
On 10/26/15, Nicolai Hähnle wrote:
On 25.10.2015 02:00, Ivan Kalvachev wrote:
Some constants (like 1.0 and 0.5) could be inlined as immediate inputs
without using
On Thu, Oct 29, 2015 at 11:28 PM, Emil Velikov
wrote:
> On 20 October 2015 at 17:40, Arnaud Vrac wrote:
> > On Tue, Oct 20, 2015 at 6:35 PM, Emil Velikov
> > wrote:
> >>
> >> On 20 October 2015 at 17:06, Julien Isorce
> >> wrote:
> >> >
> >> >
> >> > On 19 October 2015 at 17:16, Emil Velikov
On 29.10.2015 14:13, Marek Olšák wrote:
On Wed, Oct 28, 2015 at 1:00 PM, Nicolai Hähnle wrote:
Without the clamping by NumLevels, the state tracker would reallocate the
texture storage (incorrect) and even fail to copy the base level image
after reallocation, leading to the graphical glitch of
On 20 October 2015 at 17:40, Arnaud Vrac wrote:
> On Tue, Oct 20, 2015 at 6:35 PM, Emil Velikov
> wrote:
>>
>> On 20 October 2015 at 17:06, Julien Isorce
>> wrote:
>> >
>> >
>> > On 19 October 2015 at 17:16, Emil Velikov
>> > wrote:
>> >>
>> >> On 17 October 2015 at 00:14, Julien Isorce
>> >>
On 29 October 2015 at 12:05, Christian König wrote:
>
>> + drm_info = (struct drm_state *) ctx->drm_state;
>> + if (!drm_info) {
>> + FREE(drv);
>> + return VA_STATUS_ERROR_INVALID_PARAMETER;
>> + }
>> +
>> +#if GALLIUM_STATIC_TARGETS
>> + drm_fd = drm_info->fd;
On 10/27/2015 02:01 PM, samuel.pitoiset wrote:
On 27/10/2015 12:52, Emil Velikov wrote:
On 27 October 2015 at 10:50, samuel.pitoiset
wrote:
On 27/10/2015 11:37, Emil Velikov wrote:
On 22 October 2015 at 00:16, Julien Isorce
wrote:
The real fix is in nouveau_drm_winsys.c by setting dev t
Hi Julien,
One can separate the errors checks and get those separately (+stable).
I'll let others be the judge of that - I'm just going to point the
sections I have in mind.
On 29 October 2015 at 17:40, Julien Isorce wrote:
> @@ -73,6 +76,10 @@ vlVaBufferSetNumElements(VADriverContextP ctx, VAB
On 29 October 2015 at 21:12, Emil Velikov wrote:
> On 29 October 2015 at 11:12, Emil Velikov wrote:
>> Hi all,
>>
>> A slightly longer series (that builds on top of the previous sent a
>> minute ago), that moves/renames a couple of files, adds a few inline
>> wrappers, 'includes what you want' an
Yes please. Thx
Julien
On 29 October 2015 at 19:12, Christian König
wrote:
> On 29.10.2015 18:40, Julien Isorce wrote:
>
>> If formats are not the same vlVaPutImage re-creates the video
>> buffer with the right format. But if the creation of this new
>> video buffer fails then the surface looses
Am 29.10.2015 um 19:44 schrieb Oded Gabbay:
> On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger
> wrote:
>> Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
>>> Hi Roland, Jose
>>>
>>> I wanted to bring a problem I found to your attention, and discuss
>>> about it and ways to solve it.
>>>
>>> I'm w
Am 29.10.2015 um 20:33 schrieb Oded Gabbay:
> On Thu, Oct 29, 2015 at 9:25 PM, Roland Scheidegger
> wrote:
>> Am 29.10.2015 um 20:10 schrieb Oded Gabbay:
>>> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin wrote:
On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay wrote:
> However, I would hate
On Thu, Oct 29, 2015 at 9:25 PM, Roland Scheidegger wrote:
> Am 29.10.2015 um 20:10 schrieb Oded Gabbay:
>> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin wrote:
>>> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay wrote:
However, I would hate to keep the situation as is, meaning the test
pa
On Thu, Oct 29, 2015 at 12:32 AM, Iago Toral wrote:
> On Wed, 2015-10-28 at 10:58 -0700, Kristian Høgsberg wrote:
>> On Wed, Oct 28, 2015 at 10:01:40AM +0100, Samuel Iglesias Gonsálvez wrote:
>> > There is no opinions about this issue or reviews of the proposed patch
>> > after one week.
>> >
>> >
On 29.10.2015 18:40, Julien Isorce wrote:
Add support for VA_PROFILE_NONE and VAEntrypointVideoProc
in the 4 following functions:
vlVaQueryConfigProfiles
vlVaQueryConfigEntrypoints
vlVaCreateConfig
vlVaQueryConfigAttributes
Signed-off-by: Julien Isorce
Reviewed-by: Christian König
But you
Am 29.10.2015 um 20:10 schrieb Oded Gabbay:
> On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin wrote:
>> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay wrote:
>>> However, I would hate to keep the situation as is, meaning the test
>>> passes on x86-64 and fails on ppc64le.
>>
>> Sounds like it'd actual
On 29.10.2015 18:40, Julien Isorce wrote:
For now it is limited to RGBA, BGRA, RGBX, BGRX surfaces.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/surface.c | 97 -
1 file changed, 96 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state
On 29.10.2015 18:40, Julien Isorce wrote:
If formats are not the same vlVaPutImage re-creates the video
buffer with the right format. But if the creation of this new
video buffer fails then the surface looses its current buffer.
Let's just destroy the previous buffer on success.
Signed-off-by: J
On Thu, Oct 29, 2015 at 9:02 PM, Ilia Mirkin wrote:
> On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay wrote:
>> However, I would hate to keep the situation as is, meaning the test
>> passes on x86-64 and fails on ppc64le.
>
> Sounds like it'd actually be a difference between AVX and SSE4.2 as
> well
@@ -80,12 +82,46 @@ YCbCrToPipe(unsigned format)
...
+PipeToYCbCr(enum pipe_format p_format)
You should probably rename those two functions as well, cause when we
start to handle RGB formats as well the name doesn't match any more.
BTW when do you use PipeToYCbCr?
Regards,
Christian.
On 2
On 29 October 2015 at 17:40, Julien Isorce wrote:
> +
> +VAStatus
> +vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int format,
> +unsigned int width, unsigned int height,
> +VASurfaceID *surfaces, unsigned int num_surfaces,
> +VASurf
On Thu, Oct 29, 2015 at 2:44 PM, Oded Gabbay wrote:
> However, I would hate to keep the situation as is, meaning the test
> passes on x86-64 and fails on ppc64le.
Sounds like it'd actually be a difference between AVX and SSE4.2 as
well -- what happens if you run on your x86_64 chip with
LP_NATIVE
On Thu, Oct 29, 2015 at 5:31 PM, Roland Scheidegger wrote:
> Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
>> Hi Roland, Jose
>>
>> I wanted to bring a problem I found to your attention, and discuss
>> about it and ways to solve it.
>>
>> I'm working on regressions of piglit gpu.py between x86-64 an
On 20 October 2015 at 17:34, Julien Isorce wrote:
> static inline enum pipe_video_chroma_format
> ChromaToPipe(int format)
> {
> switch (format) {
> + case VA_RT_FORMAT_YUV400:
> + return PIPE_VIDEO_CHROMA_FORMAT_400;
Intentional ? We're barely handling it so might as well not bothe
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 11 +++
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.
From: Marek Olšák
pipe->flush never returned SDMA fences. This fixes it.
This is only an issue on amdgpu where fences can signal out of order.
---
src/gallium/drivers/radeon/r600_pipe_common.c | 64 +++
1 file changed, 56 insertions(+), 8 deletions(-)
diff --git a/src/ga
On 29 October 2015 at 17:15, Grazvydas Ignotas wrote:
> Hi,
>
> On Thu, Oct 29, 2015 at 6:21 PM, Emil Velikov
> wrote:
>> On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
>> wrote:
>>> This was causing compilation issues when one of its providers wasn’t
>>> already included before gbm.h.
>> Cc:
On Thu, Oct 29, 2015 at 10:15 AM, Grazvydas Ignotas wrote:
> Hi,
>
> On Thu, Oct 29, 2015 at 6:21 PM, Emil Velikov
> wrote:
>> On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
>> wrote:
>>> This was causing compilation issues when one of its providers wasn’t
>>> already included before gbm.h.
>
Also add RGBA, RGBX and BGRX.
Also extend ChromaToPipe and implement PipeToYCbCr.
Note that gstreamer-vaapi check all the VAImageFormat fields.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/image.c | 18 +++---
src/gallium/state_trackers/va/va_private.h | 38 ++
On 2015-10-29 02:17:20, Iago Toral wrote:
> On Thu, 2015-10-29 at 00:50 -0700, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen
> > ---
> > src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 6 --
> > src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 6 --
> > 2 files changed, 8 insertions(+),
If formats are not the same vlVaPutImage re-creates the video
buffer with the right format. But if the creation of this new
video buffer fails then the surface looses its current buffer.
Let's just destroy the previous buffer on success.
Signed-off-by: Julien Isorce
---
src/gallium/state_tracker
This patch allows to use gallium vaapi without requiring
a X server running for your second graphic card.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/Makefile.am | 9
src/gallium/state_trackers/va/context.c | 70 ---
2 files changed, 73 inse
Add support for VPP in the following functions:
vlVaCreateContext
vlVaDestroyContext
vlVaBeginPicture
vlVaRenderPicture
vlVaEndPicture
Add support for VAProcFilterNone in:
vlVaQueryVideoProcFilters
vlVaQueryVideoProcFilterCaps
vlVaQueryVideoProcPipelineCaps
Add handleVAProcPipelineParameterBuffer
Add support for VA_PROFILE_NONE and VAEntrypointVideoProc
in the 4 following functions:
vlVaQueryConfigProfiles
vlVaQueryConfigEntrypoints
vlVaCreateConfig
vlVaQueryConfigAttributes
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/config.c | 20
src/galliu
And apply relatives change to:
vlVaBufferSetNumElements
vlVaCreateBuffer
vlVaMapBuffer
vlVaUnmapBuffer
vlVaDestroyBuffer
vlVaPutImage
It is unfortunate that there is no proper va buffer type and struct
for this. Only possible to use VAImageBufferType which is normally
used for normal user data arr
I.e. implements:
VaAcquireBufferHandle
VaReleaseBufferHandle
for memory of type VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME
And apply relatives change to:
vlVaMapBuffer
vlVaUnMapBuffer
vlVaDestroyBuffer
Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver
Tested with gstreamer-vaapi wit
For now it is limited to RGBA, BGRA, RGBX, BGRX surfaces.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/surface.c | 97 -
1 file changed, 96 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_tr
Inspired from http://cgit.freedesktop.org/vaapi/intel-driver/
especially src/i965_drv_video.c::i965_CreateSurfaces2.
This patch is mainly to support gstreamer-vaapi and tools that uses
this newer libva API. The first advantage of using VaCreateSurfaces2
over existing VaCreateSurfaces, is that it i
On Thu, Oct 22, 2015 at 2:34 AM, Neil Roberts wrote:
> Previously this extension was only enabled when blitting between two
> multisampled buffers. However I don't think it does any harm to just
> enable it all the time. The ‘enable’ option is used instead of
> ‘require’ so that the shader will st
Hi,
On Thu, Oct 29, 2015 at 6:21 PM, Emil Velikov wrote:
> On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
> wrote:
>> This was causing compilation issues when one of its providers wasn’t
>> already included before gbm.h.
> Cc: "11.0"
> Reviewed-by: Emil Velikov
>
> I'll push this later on to
On 2015-10-29 03:04:38, Iago Toral wrote:
> On Thu, 2015-10-29 at 00:52 -0700, Jordan Justen wrote:
> > Signed-off-by: Jordan Justen
> > ---
> > src/mesa/main/api_validate.c | 2 +-
> > src/mesa/main/pipelineobj.c | 11 +++
> > 2 files changed, 12 insertions(+), 1 deletion(-)
> >
> > d
Hi Christian,
Ok I'll send all of it including last 2 patches about dmabuf export. I
addressed all remarks already in my local branch and I did some round of
testing, so it should be ok.
Cheers
Julien
On 29 October 2015 at 12:10, Christian König
wrote:
> Hi Julien,
>
> if Emil or Ilia have no
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: 29 October 2015 12:29
To: Julien Isorce; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 2/2] st/va: add support to export a surface as
dmabuf
> @@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverConte
From: Marek Olšák
Untested. I don't have Stoney.
---
src/gallium/drivers/radeonsi/si_state.c | 28
src/gallium/drivers/radeonsi/sid.h | 20 ++--
2 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_stat
Ack. And I'll move this bit at the end just before the other FREE. Thx
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: 29 October 2015 12:22
To: Julien Isorce; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 1/2] st/va: implement VaDeriveImage
Ack. I confirm it still works without it. So I'll remove it. Thx
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: 29 October 2015 14:02
To: Julien Isorce; mesa-dev@lists.freedesktop.org
Cc: emil.l.veli...@gmail.com
Subject: Re: [Mesa-dev] [PATCH v2 7/8] st/v
https://bugs.freedesktop.org/show_bug.cgi?id=92645
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Emmanuel,
On 29 October 2015 at 15:22, Emmanuel Gil Peyrot
wrote:
> This was causing compilation issues when one of its providers wasn’t
> already included before gbm.h.
Cc: "11.0"
Reviewed-by: Emil Velikov
I'll push this later on today. For future patches please include your
s-o-b line.
-
Am 29.10.2015 um 12:27 schrieb Oded Gabbay:
> Hi Roland, Jose
>
> I wanted to bring a problem I found to your attention, and discuss
> about it and ways to solve it.
>
> I'm working on regressions of piglit gpu.py between x86-64 and
> ppc64le, when running with llvmpipe.
>
> One of the regressio
This was causing compilation issues when one of its providers wasn’t
already included before gbm.h.
---
src/gbm/main/gbm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 2708e50..8db2153 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@
From: Marta Lofstedt
From the ARB_compute_shader specification:
"An INVALID_OPERATION error is generated [...] if is
less than zero or not a multiple of the size, in basic machine
units, of uint."
However, OpenGL ES 3.1 specification, section 17 and OpenGL 4.5
specification, section 19, has th
+if(src_surface->fence) {
+ screen->fence_finish(screen, src_surface->fence, PIPE_TIMEOUT_INFINITE);
+ screen->fence_reference(screen, &src_surface->fence, NULL);
+}
That shouldn't be necessary cause all render operations to the same
surface are pipelined anyway.
Regards,
Ch
On 22.10.2015 18:37, Julien Isorce wrote:
Add support for VA_PROFILE_NONE and VAEntrypointVideoProc
in the 4 following functions:
vlVaQueryConfigProfiles
vlVaQueryConfigEntrypoints
vlVaCreateConfig
vlVaQueryConfigAttributes
Signed-off-by: Julien Isorce
Reviewed-by: Christian König
---
s
On Wed, Oct 28, 2015 at 1:00 PM, Nicolai Hähnle wrote:
> Without the clamping by NumLevels, the state tracker would reallocate the
> texture storage (incorrect) and even fail to copy the base level image
> after reallocation, leading to the graphical glitch of
> https://bugs.freedesktop.org/show_b
@@ -108,6 +109,9 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, void
**pbuff)
if (!buf)
return VA_STATUS_ERROR_INVALID_BUFFER;
+ if (buf->export_refcount > 0)
+ return VA_STATUS_ERROR_INVALID_BUFFER;
Why it is illegal to CPU map a buffer which is exported?
+
Patch #1:
+ if (buf->data)
+ FREE(buf->data);
FREE() usually does a NULL check anyway.
Apart from that minor nitpick the patch is Reviewed-by: Christian König
Regards,
Christian.
On 29.10.2015 12:47, Julien Isorce wrote:
And apply relatives change to:
vlVaBufferSetNumElements
vlVaCr
Francisco Jerez writes:
> Chris Wilson writes:
>
>> On Sat, Oct 03, 2015 at 05:57:05PM +0300, Francisco Jerez wrote:
>>> Jordan Justen writes:
>>>
>>> > From: Francisco Jerez
>>> >
>>> > Fixes
>>> > arb_shader_image_load_store/execution/load-from-cleared-image.shader_test
>>> >
>>> > Cc: Chr
Am 29.10.2015 um 10:24 schrieb Ivan Kalvachev:
> Configuring smtp server is too much hassle for a single patch and I
> would like to avoid writing my email credentials if possible.
> If I'm about to send more patches, then I guess I would have to do that.
You might want to look into "git imap-send
Hi Julien,
if Emil or Ilia have no further comments please send out your full set
of patches once more I would like to get this pusched upstream.
Best regards,
Christian.
On 17.10.2015 01:14, Julien Isorce wrote:
This patch serie adds initial support for Video Post Processing.
It also implem
+ drm_info = (struct drm_state *) ctx->drm_state;
+ if (!drm_info) {
+ FREE(drv);
+ return VA_STATUS_ERROR_INVALID_PARAMETER;
+ }
+
+#if GALLIUM_STATIC_TARGETS
+ drm_fd = drm_info->fd;
+#else
+ drm_fd = dup(drm_info->fd);
+#endif
+
+ if (drm_fd < 0)
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/virgl_context.c | 2 +-
src/gallium/drivers/virgl/virgl_encode.c | 4 ++--
src/gallium/drivers/virgl/virgl_encode.h | 5 +
src/gallium/drivers/virgl/virgl_resource.c | 4 ++--
src/gallium/drivers/virgl/virgl_screen.h | 2 +-
5 f
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index d9b4d58..0616de3 100644
--- a/s
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 5 ++---
src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
b/src/gallium/winsys/virgl/dr
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/virgl_query.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/virgl/virgl_query.c
b/src/gallium/drivers/virgl/virgl_query.c
index ea50f2f..b06635b 100644
--- a/src/gallium/drivers/v
The uppercase versions are wrappers which must be matched.
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
b/src/gallium/winsys/virgl/drm/virgl_drm
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/virgl_buffer.c| 6 +-
src/gallium/drivers/virgl/virgl_context.c | 98 ++---
src/gallium/drivers/virgl/virgl_context.h | 17 +
src/gallium/drivers/virgl/virgl_encode.c| 2 +-
src/gallium/drivers/vir
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 10 +-
src/gallium/winsys/virgl/drm/virgl_drm_winsys.h | 14 ++
src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 10 +-
src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h |
The screen already has a pointer to the (base) winsys object.
With the latter of which implemented/sub-classed as either drm or sw
based one, depending on the target.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/virgl_public.h | 1 -
src/gallium/drivers/virgl/virgl_screen.c | 1 -
s
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.h
index eac1d3e..a547654 100644
--- a/src/gallium/winsys/virgl/drm/
The only two remaining cases of (struct virgl_resource *) require a
closer look. Either the error checking is missing or the arguments
provided feel wrong.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/virgl_buffer.c| 2 +-
src/gallium/drivers/virgl/virgl_context.c | 28 ++
Wrap some of the 'omg it's getting out of hand' long lines, and
re-indent where things feel off.
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c| 83 ---
.../winsys/virgl/vtest/virgl_vtest_socket.c| 13 ++-
.../winsys/virgl/vtest/virgl_vt
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/virgl_drm_winsys.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index 11542f5..d9b4d58 100644
--- a/s
Include what you want, rather than relying on a header foo.h N levels
down the include chain, to provide something that you need.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/virgl_buffer.c| 2 ++
src/gallium/drivers/virgl/virgl_context.c | 7 ++-
src/gal
Provide a more meaningful name considering it's purpose.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/Makefile.sources | 2 +-
src/gallium/drivers/virgl/virgl.h | 51 --
src/gallium/drivers/virgl/virgl_context.c | 2 +-
src/gallium/drivers/vir
Strictly speaking virgl_hw.h should reside in the driver folder, as
it describes the hardware. Moving it allows us to nuke the following
strange dependency
winsys/vtest > driver > winsys/drm
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/Makefile.sources | 1 +
src/gallium/
I.e. implements:
VaAcquireBufferHandle
VaReleaseBufferHandle
for memory of type VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME
And apply relatives change to:
vlVaMapBuffer
vlVaUnMapBuffer
vlVaDestroyBuffer
Implementation inspired from cgit.freedesktop.org/vaapi/intel-driver
Tested with gstreamer-vaapi wit
This 2 patches allow to derive a va surface as a va image.
Which one can be exported as dmabuf by calling VaAcquireBufferHandle.
I have tested these patches with gstreamer-vaapi and nouveau driver.
The pipeline looks like:
gstvaapidecode:(vasurface, NV12) -> gstvaapipostproc:(dmabuf, RGBA) ->
gl
And apply relatives change to:
vlVaBufferSetNumElements
vlVaCreateBuffer
vlVaMapBuffer
vlVaUnmapBuffer
vlVaDestroyBuffer
vlVaPutImage
It is unfortunate that there is no proper va buffer type and struct
for this. Only possible to use VAImageBufferType which is normally
used for normal user data arr
On 29 October 2015 at 09:24, Ivan Kalvachev wrote:
> On 10/29/15, Ilia Mirkin wrote:
>> On Wed, Oct 28, 2015 at 8:52 PM, Ivan Kalvachev
>> wrote:
>>> I'm attaching v3 of the patch. Same as v2, but without the extra empty
>>> line.
>>
>> FYI, there's a lot of overhead to reviewing an attached pat
Hi Roland, Jose
I wanted to bring a problem I found to your attention, and discuss
about it and ways to solve it.
I'm working on regressions of piglit gpu.py between x86-64 and
ppc64le, when running with llvmpipe.
One of the regressions manifests itself in 2 tests,
clip-distance-bulk-copy and cl
On 29 October 2015 at 11:12, Emil Velikov wrote:
> Hi all,
>
> A slightly longer series (that builds on top of the previous sent a
> minute ago), that moves/renames a couple of files, adds a few inline
> wrappers, 'includes what you want' and related fixes.
>
> As some of these can be seen as bike
Hi all,
A slightly longer series (that builds on top of the previous sent a
minute ago), that moves/renames a couple of files, adds a few inline
wrappers, 'includes what you want' and related fixes.
As some of these can be seen as bikeshedding, although rest assured
there is a method to the ma
Hi all,
A slightly longer series (that builds on top of the previous sent a
minute ago), that moves/renames a couple of files, adds a few inline
wrappers, 'includes what you want' and related fixes.
As some of these can be seen as bikeshedding, although rest assured
there is a method to the ma
Hi all,
A slightly longer series (that builds on top of the previous sent a
minute ago), that moves/renames a couple of files, adds a few inline
wrappers, 'includes what you want' and related fixes.
As some of these can be seen as bikeshedding, although rest assured
there is a method to the ma
From: Emil Velikov
... and add the missing files while we're at it.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/Makefile.am | 12 ++--
src/gallium/drivers/virgl/Makefile.sources | 17 +
2 files changed, 19 insertions(+), 10 deletions(-)
create mode 1
From: Emil Velikov
Signed-off-by: Emil Velikov
---
src/gallium/winsys/virgl/drm/Makefile.sources | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/virgl/drm/Makefile.sources
b/src/gallium/winsys/virgl/drm/Makefile.sources
index c0baed8..eca8eb6 100644
From: Emil Velikov
Use the relevant GALLIUM_foo_CFLAGS which has all the requirements
(not to mention VISIBITY_CFLAGS) and keep ../ out of the include
directives.
Signed-off-by: Emil Velikov
---
src/gallium/drivers/virgl/Makefile.am | 5 +
src/gallium/drivers/virgl/virgl.h
1 - 100 of 138 matches
Mail list logo
