On 15.02.2014 13:14, Andy Furniss wrote:
Thanks Grigori for doing this - looks really good on HD stuff I've
tested and of course is easily fast enough, unlike anything on the CPU
at high res.
Any plans for the future?
Well, adding edge-guided spatial interpolation for the temporal-spatial
/vl_deint_filter.c
b/src/gallium/auxiliary/vl/vl_deint_filter.c
new file mode 100644
index 000..9b05154
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_deint_filter.c
@@ -0,0 +1,491 @@
+/**
+ *
+ * Copyright 2013 Grigori Goronzy g
---
src/gallium/state_trackers/vdpau/mixer.c | 69 ++--
src/gallium/state_trackers/vdpau/query.c | 1 +
src/gallium/state_trackers/vdpau/vdpau_private.h | 7 +++
3 files changed, 73 insertions(+), 4 deletions(-)
diff --git
v2: adjust limits for radeonsi and llvmpipe
v3: add documentation
Cc: 10.1 mesa-sta...@lists.freedesktop.org
---
src/gallium/docs/source/screen.rst | 6 ++
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
src/gallium/drivers/i915/i915_screen.c | 5 +
On 06.02.2014 02:46, Michel Dänzer wrote:
+ case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+ return 16384;
radeonsi currently can't handle more than 4095 total output components,
as the buffer resource for writing to the GSVS ring only has 14 bits for
the stride in
v2: adjust limits for radeonsi and llvmpipe
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
src/gallium/drivers/i915/i915_screen.c | 5 +
src/gallium/drivers/ilo/ilo_screen.c | 3 +++
src/gallium/drivers/llvmpipe/lp_screen.c | 3 +++
On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would have
been alright if it wasn't for this bit in
http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:
2) Can the application still use the buffer using the
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
src/gallium/drivers/i915/i915_screen.c | 5 +
src/gallium/drivers/ilo/ilo_screen.c | 3 +++
src/gallium/drivers/llvmpipe/lp_screen.c | 3 +++
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 2 ++
On 04.02.2014 00:53, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
attempt to calculate a better value for array size to avoid breaking apps.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/drivers/r600/r600_shader.c | 2 +-
1 file changed, 1 insertion(+), 1
Ping? Can anyone review this, please?
Grigori
On 27.11.2013 00:15, Grigori Goronzy wrote:
---
src/glsl/glsl_types.cpp | 61 +++--
src/glsl/glsl_types.h | 7 ++
2 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/src/glsl
---
src/glsl/glsl_types.cpp | 61 +++--
src/glsl/glsl_types.h | 7 ++
2 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index f740130..6c9727e 100644
--- a/src/glsl/glsl_types.cpp
Unnamed record types are assigned to separate types per stage, e.g.
uniform struct { ... } a;
if defined in both vertex and fragment shader, will result in two
separate types of different name. When linking the shader, this
results in a type conflict. However, there is no reason why this
should
Grigori
From 386dc4f201a65a2a8740c8c9f4a039d5c8209a9c Mon Sep 17 00:00:00 2001
From: Grigori Goronzy g...@chown.ath.cx
Date: Sun, 24 Nov 2013 20:24:58 +0100
Subject: [PATCH] WIP: fix unnamed struct type conflicts
If two shader stages define the same unnamed struct type, they will
conflict
From: Vadim Girlin vadimgir...@gmail.com
v2: make it actually work, improve condition
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68503
Cc: 10.0 mesa-sta...@lists.freedesktop.org
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_bc.h|
, but I don't
know if this is a realistic goal.
Best regards
Grigori
Thanks for the help,
Christian.
Am 06.11.2013 00:35, schrieb Grigori Goronzy:
Otherwise OutputSurface interop has funny results sometimes.
This fixes interop with the mpv media player.
---
src/gallium/state_trackers/vdpau
Otherwise OutputSurface interop has funny results sometimes.
This fixes interop with the mpv media player.
---
src/gallium/state_trackers/vdpau/output.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index
On 26.10.2013 16:31, Peter Frühberger wrote:
Hi,
I looked at the openmax decoder posted yesterday and have seen that
only two fields are missing to also decode hi10p with the current
vdpau uvd infrastructure in place.
I mailed two patches to the vdpau mailing list in order to get the API
Textures that likely reside in VRAM, are mapped for reading and
don't require direct mapping should be staged into GTT, to avoid bad
performance. This fixes readback performance of VDPAU surfaces.
---
src/gallium/drivers/radeon/r600_texture.c | 6 ++
1 file changed, 6 insertions(+)
diff
This new bind flag forces linear storage, but does not have other
side effects like R600_RESOURCE_FLAG_TRANSFER.
---
src/gallium/drivers/r600/r600_uvd.c | 6 +++---
src/gallium/drivers/radeonsi/radeonsi_uvd.c | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git
Add simple plain C routines for NV12-YV12 and YUYV-UYVY
conversions. The NV12-YV12 conversion is commonly used, for instance
by VLC.
---
src/gallium/state_trackers/vdpau/surface.c | 125 +++--
1 file changed, 117 insertions(+), 8 deletions(-)
diff --git
On 10.10.2013 11:41, Christian König wrote:
Am 09.10.2013 22:19, schrieb Grigori Goronzy:
R600_RESOURCE_FLAG_TRANSFER forces direct mapping, and reading from
VRAM is simply too slow. VDPAU GetBitsYCbCr is unusuable. Change to
the new PIPE_BIND_LINEAR and adjust r600_transfer_map so that it uses
We should be able to safely set the framebuffer state without a
fragment shader bound. bind_ps_state will take care of updating the
necessary state bits later.
---
src/gallium/drivers/r600/evergreen_state.c | 4 +++-
src/gallium/drivers/r600/r600_state.c | 4 +++-
2 files changed, 6
We should be able to safely set the framebuffer state without a
fragment shader bound. bind_ps_state will take care of updating the
necessary state bits later.
v2: check in update_db_shader_control
---
src/gallium/drivers/r600/evergreen_state.c | 23 +++
Add simple plain C routines for NV12-YV12 and YUYV-UYVY
conversions. The NV12-YV12 conversion is commonly used, for instance
by VLC.
---
src/gallium/state_trackers/vdpau/surface.c | 125 +++--
1 file changed, 117 insertions(+), 8 deletions(-)
diff --git
R600_RESOURCE_FLAG_TRANSFER forces direct mapping, and reading from
VRAM is simply too slow. VDPAU GetBitsYCbCr is unusuable. Change to
the new PIPE_BIND_LINEAR and adjust r600_transfer_map so that it uses
a staging texture.
---
src/gallium/drivers/r600/r600_uvd.c | 6 +++---
UVD can only support NV12 in the case of hardware decoding, but we
can still use all other formats for software decoding. Use the UNKNOWN
profile to signal that we're not interesting in hardware decoding.
v2: use profile instead of entrypoint
---
src/gallium/drivers/radeon/radeon_uvd.c | 7
The DPB size calculations seem to be off; there is various random
corruption happening, even with advanced profile. Always assuming
a minimum number of references appears to fix it, similarly to
H.264. This might overallocate the DPB. Also clean up the SPS/PPS
field setup so that it matches VC-1
As per API specification, it is legal to supply a NULL procamp. In this
case, a CSC matrix according to the colorspace should be generated,
but no further adjustments are made.
Addresses:
https://trac.videolan.org/vlc/ticket/9281
https://bugs.freedesktop.org/show_bug.cgi?id=68792
---
OutputSurfaces have simple YCbCr rendering functionality built in,
but so far only 4:2:0 subsampling worked correctly. This fixes 4:2:2
and 4:4:4 formats.
---
src/gallium/state_trackers/vdpau/output.c| 2 +-
src/gallium/state_trackers/vdpau/vdpau_private.h | 23 +++
2
pipe_screen::fence_finish with zero timeout returns quickly and
doesn't wait at all. Fix that, and also delete the fence afterwards,
so that QuerySurfaceStatus returns the right state later.
Addresses:
https://trac.videolan.org/vlc/ticket/9281
https://bugs.freedesktop.org/show_bug.cgi?id=68792
On 07.10.2013 11:25, Christian König wrote:
Am 01.10.2013 21:12, schrieb Ilia Mirkin:
On Tue, Oct 1, 2013 at 3:06 PM, Grigori Goronzy g...@chown.ath.cx
wrote:
UVD can only support NV12 in the case of hardware decoding, but we
can still use all other formats for software decoding. Use
All texture instructions can use offsets, not just TXF. Offsets into
the literals array were wrong, too.
---
src/gallium/drivers/r600/r600_shader.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
On 03.10.2013 00:12, Grigori Goronzy wrote:
All texture instructions can use offsets, not just TXF. Offsets into
the literals array were wrong, too.
BTW, I just noticed it now: this fixes the fs-textureOffset-2D piglit
test, which unfortunately does not appear to be part of any of the test
Fixes regression on r600g due to fast clear introduced by commit
edbbfac6.
---
src/gallium/state_trackers/egl/x11/native_dri2.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/state_trackers/egl/x11/native_dri2.c
b/src/gallium/state_trackers/egl/x11/native_dri2.c
UVD can only support NV12 in the case of hardware decoding, but we
can still use all other formats for software decoding. Use the UNKNOWN
entrypoint to signal that we're not interesting in hardware decoding.
---
src/gallium/drivers/radeon/radeon_uvd.c | 7 +--
MPEG-2 and later video standards align the chroma sample position
horizontally with the leftmost luma sample position. Add a half-texel
offset to the chroma texture sampling coordinate to sample at the
this position instead of sampling in the center between the luma
texels. This avoids minor color
On 30.09.2013 10:06, Michel Dänzer wrote:
On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote:
after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with
my RV730 (AGP).
Same problem on PALM. Bisection shows that it is caused by commit
68f6dec32. The initialization order
UVD was checked before the info fields were initialized. Introduced
by commit 68f6dec32.
---
src/gallium/drivers/r600/r600_pipe.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index
Allocate a CMASK on demand and use it to fast clear single-sample
colorbuffers. Both FBOs and window system colorbuffers are fast
cleared. Expand as needed when colorbuffers are mapped or displayed
on screen.
v2: cosmetics, move transfer expansion into dma_blit
---
v2: check for NULL cbufs
---
src/gallium/drivers/r600/evergreen_state.c | 24 +++-
src/gallium/drivers/r600/r600_hw_context.c | 18 ++
src/gallium/drivers/r600/r600_resource.h | 3 +++
src/gallium/drivers/r600/r600_texture.c| 25 -
From: Marek Olšák mar...@gmail.com
r600g needs explicit flushing before DRI2 buffers are presented on the screen.
v2: add (stub) implementations for all drivers, fix frontbuffer flushing
v3: fix galahad
---
src/gallium/docs/source/context.rst | 13 +
From: Marek Olšák mar...@gmail.com
r600g needs explicit flushing before DRI2 buffers are presented on the screen.
v2: add (stub) implementations for all drivers, fix frontbuffer flushing
---
src/gallium/docs/source/context.rst | 13 +
---
src/gallium/drivers/r600/evergreen_state.c | 24 +++-
src/gallium/drivers/r600/r600_hw_context.c | 12 +---
src/gallium/drivers/r600/r600_resource.h | 3 +++
src/gallium/drivers/r600/r600_texture.c| 25 -
4 files changed, 55
Allocate a CMASK on demand and use it to fast clear single-sample
colorbuffers. Both FBOs and window system colorbuffers are fast
cleared. Expand as needed when colorbuffers are mapped or displayed
on screen.
---
src/gallium/drivers/r600/evergreen_state.c | 11 +
On 09.09.2013 16:09, Marek Olšák wrote:
/* Check colorbuffers. */
for (i = 0; i rctx-framebuffer.state.nr_cbufs; i++) {
+ struct r600_texture *tex =
+ (struct
r600_texture*)rctx-framebuffer.state.cbufs[i]-texture;
+
Please check if
On 16.07.2013 19:26, Marek Olšák wrote:
Surprisingly all drivers supporting MSAA can already do this (r300g and r600g
for sure) and I think Christoph wanted to have this feature for his Nouveau
drivers anyway.
OK, they can do it, but is it actually any faster than doing a resolve
and regular
On 17.07.2013 02:05, Marek Olšák wrote:
No, it's not faster, but it's not slower either.
Now that I think about it, I can't come up with a good shader-based
algorithm for the resolve operation.
I don't think Christoph's approach that an MSAA texture can be viewed
as a larger single-sample
On 12.07.2013 16:19, Jose Fonseca wrote:
I admit I haven't fully understood what's being proposed yet. But just a few
quick words.
I always wanted to have a present method that ensures that the contents of a
resource is made visible to whatever the consumer is (full-screen flip, blit to
This interface is used to expand fast-cleared window system
colorbuffers.
---
src/gallium/include/pipe/p_context.h | 8
src/gallium/state_trackers/dri/common/dri_drawable.c | 4
src/gallium/state_trackers/dri/drm/dri2.c| 8 ++--
3 files changed, 18
---
src/gallium/drivers/r600/evergreen_state.c | 24 +++-
src/gallium/drivers/r600/r600_hw_context.c | 12 +---
src/gallium/drivers/r600/r600_resource.h | 3 +++
src/gallium/drivers/r600/r600_texture.c| 25 -
4 files changed, 55
Allocate a CMASK on demand and use it to fast clear single-sample
colorbuffers. Both FBOs and window system colorbuffers are fast
cleared. Expand as needed when colorbuffers are mapped or displayed
on screen.
---
src/gallium/drivers/r600/evergreen_state.c | 11
On 12.06.2013 00:04, Grigori Goronzy wrote:
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
Fast clear is used only when all bound
On 11.06.2013 02:41, Marek Olšák wrote:
+
+ /* cannot pack color, needs support in u_format */
+ if (desc-pack_rgba_float == NULL) {
+ return false;
+ }
Hi Grirogi,
Is this for disallowing integer textures? You probably
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
Fast clear is used only when all bound colorbuffers fulfill certain
conditions: a
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
Fast clear is used only when all bound colorbuffers fulfill certain
conditions: a
This is my first try to contribute anything useful to Mesa, so please
bear with me. This is not finished, but I'd like feedback to make sure
the code's quality and style is in line with what is expected in Mesa.
___
mesa-dev mailing list
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
---
src/gallium/drivers/r600/evergreen_state.c | 8 +++-
On 08.06.2013 00:40, Marek Olšák wrote:
Also the fast clear
shouldn't be used for array, cube, and 3D textures unless all layers
are cleared together.
OK. I hadn't really thought about these.
One more thing. If you don't use piglit, I recommend using it before
sending patches to the mailing
On 31.05.2013 14:37, Vadim Girlin wrote:
There are no regressions on evergreen with piglit tests or any
other apps that I tested, with and without llvm backend.
(Issue with Unigine Heaven that I mentioned on #dri-devel
yesterday was in fact caused by my own well-hidden bug, now it's fixed).
According to ISA docs, the range is 1..64, so effectively
bytes_to_fetch-1.
---
src/gallium/drivers/r600/r600_shader.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 81ed3ce..0444579
101 - 160 of 160 matches
Mail list logo
