https://bugs.freedesktop.org/show_bug.cgi?id=70264
--- Comment #1 from Pekka Paalanen ---
That proposed fix does not sound right. If you look at pkg-config manual, there
are the PKG_CONFIG_ALLOW_SYSTEM_CFLAGS and PKG_CONFIG_ALLOW_SYSTEM_LIBS
environment variables. pkg-config itself *deliberately*
Hello all,
I really apologize, being new to git send-email and git format I managed to
make a number of mistakes when I sent the patches for documentation:
1) I sent the patch set twice.
2) The second time I sent the patch set, I sent the first patch twice.
The threads for each are labele
---
doxygen/all.doxy | 1 +
src/gbm/gbm.doxy_text| 15 ++
src/mesa/drivers/dri/i965/i965.doxy_text | 176 +
src/mesa/main/main.doxy_text | 257 +++
src/mesa/program/program.doxy_text |
---
src/gbm/main/gbm.h | 10 +-
src/mapi/glapi/glapi.h | 17 +
src/mesa/main/context.c | 45 -
src/mesa/program/program.h | 8 +---
src/mesa/swrast/s_context.h | 10 +-
src/mesa/tnl/t_context.h|
---
doxygen/all.doxy | 1 +
src/gbm/gbm.doxy_text| 15 ++
src/mesa/drivers/dri/i965/i965.doxy_text | 176 +
src/mesa/main/main.doxy_text | 257 +++
src/mesa/program/program.doxy_text |
---
src/gbm/main/gbm.h | 10 +-
src/mapi/glapi/glapi.h | 17 +
src/mesa/main/context.c | 45 -
src/mesa/program/program.h | 8 +---
src/mesa/swrast/s_context.h | 10 +-
src/mesa/tnl/t_context.h|
On 27 September 2013 22:24, Vinson Lee wrote:
> Fixes "Uninitialized scalar field" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Paul Berry
>
> diff --git a/src/mesa/d
https://bugs.freedesktop.org/show_bug.cgi?id=70264
Priority: medium
Bug ID: 70264
Assignee: mesa-dev@lists.freedesktop.org
Summary: EGL pkg-config does not provide correct cflags
Severity: minor
Classification: Unclassified
O
BLORP performs blits by drawing a rectangle with a shader that samples
from the source texture, and writes color data to the destination.
The sampler always returns 32-bit RGBA float data, regardless of the
source format's component ordering or data type. Likewise, the render
target write message
The previous code for sRGB overrides assumes that the source and
destination formats are equal, other than the color space. This won't
be feasible when we add support for format conversions.
Here are a few cases, and how the old code handled them:
1. RGB8 -> SRGB8, MSAA ==> SRGB8 -> SRGB8
We could conceivably use BRW_SURFACEFORMAT_R24_UNORM_X8_TYPELESS for
Z24 source images, allowing conversions from Z24 to either Z16 or Z32F.
Unfortunately, we can't use it for destination images since it isn't
supported as a render target.
Using different formats for sources or destinations would
Currently, all that matters is that we copy the correct number of bits,
so any format that has 32-bits of data will work fine.
Once BLORP begins handling format conversions, the sampler will need to
correctly interpret the data. We don't need a depth format, but we do
need the right number of com
Currently, all that matters is that we copy the correct number of bits,
so any format that has 16-bits of data will work fine.
Once BLORP begins handling format conversions, the sampler will need to
correctly interpret the data. We don't need a depth format, but we do
need the right number of com
Once blorp gains the ability to do format conversions, it's conceivable
that the source format may be texturable but not supported as a render
target. This would break Paul's code, which assumes that it can use the
render_target_format array even for the source format.
There are three ways to con
This allows us to determine whether we're setting up a format for
the source (as a texture) or destination (as a render target).
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 3 ++-
src/mesa/drivers/dri/i965/brw_blorp.h | 3 ++-
src/mesa/drivers/dri/i
This series introduces support for blitting and CopyTexSubImage with
format conversions via the BLORP engine. Previously, we fell back to
the meta paths, which fell back to unpack/pack code, which was pretty
dire for performance.
In particular, this series makes Legends of Aethereus (an RPG that
FYI, I have just realized VISIBILITY_CFLAGS cannot be applied to
libdricore, because it needs to export everything. (it's a shared core
Mesa library)
Marek
On Mon, Oct 7, 2013 at 4:27 PM, Emil Velikov wrote:
> On 07/10/13 14:21, Tom Stellard wrote:
>> On Mon, Oct 07, 2013 at 01:52:35PM +0200, Ma
From: Christopher James Halse Rogers
Otherwise the default is TYPE_SHARED, which will flink the bo. This seems
rather unnecessary for a simple stride query.
---
src/gallium/state_trackers/dri/drm/dri2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
From: Christopher James Halse Rogers
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 107 --
1 file changed, 83 insertions(+), 24 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 5ddbc00..9
From: Christopher James Halse Rogers
---
src/gallium/winsys/intel/drm/intel_drm_winsys.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/winsys/intel/drm/intel_drm_winsys.c
b/src/gallium/winsys/intel/drm/intel_drm_winsys.c
index 521762d..d7ec919 100644
--- a/src/gallium/winsys/
From: Maarten Lankhorst
---
src/gallium/drivers/nouveau/nouveau_screen.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
b/src/gallium/drivers/nouveau/nouveau_screen.c
index e453556..94d1927 100644
--- a/src/gallium/dr
From: Christopher James Halse Rogers
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
src/gallium/drivers/nouveau/nouveau_screen.c | 6 ++
src/gallium/include/state_tracker/drm_driver.h| 9 ++---
src/gallium/state_trackers/dri/drm/dri2.c |
This is a prerequisite for the Mir EGL platform, which I'm sure everyone is
excited about.
It's also necessary for Wayland hybrid graphics support.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/me
From: Christopher James Halse Rogers
It's a map of GEM name->bo, so identify it as such
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeo
From: Christopher James Halse Rogers
*ish
---
src/gallium/state_trackers/dri/drm/dri2.c | 118 +++---
1 file changed, 108 insertions(+), 10 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index b4f1818..a6a
On 21 September 2013 16:59, Eric Anholt wrote:
> The UD values were getting set up as floats. This happened to work out
> because they were used as the second argument where the first was a dword,
> and gen6+ doesn't do source conversions. But it did trigger fulsim
> warnings, and it meant if y
On 10/01/2013 02:07 PM, Kenneth Graunke wrote:
> On 10/01/2013 06:31 AM, Gaetan Nadon wrote:
>> On 13-09-28 04:23 PM, Emil Velikov wrote:
>>> On 28/09/13 20:00, Gaetan Nadon wrote:
The EGL library has some references to x11 but it gets the link flags
from the XCB_DRI2_LIBS iff HAVE_EGL_PL
On 07/10/13 16:48, Tom Stellard wrote:
> On Sat, Sep 28, 2013 at 03:46:21PM +0100, Emil Velikov wrote:
>> Use PKG_CHECK_MODULE over requesting the user to setup the
>> option at configure time. Drop unused EXPAT_INCLUDE and add
>> EXPAT_CFLAGS to all classic/dri and gallium/dri targets.
>>
>> Signe
v2: Don't create new function in backend_instruction.
Cc: Paul Berry
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 15 ++-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 15 ++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
On 09/15/2013 12:16 AM, Kristian Høgsberg wrote:
Hi,
This little series adds support for creating EGLSurfaces with color buffers
using the ARGB2101010 pixel format. We the new KMS addFB2 ioctl we can
create KMS framebuffers with that format and this series ends up adding
the pixel format to gbm
Emilio Pozuelo Monfort writes:
> Signed-off-by: Emilio Pozuelo Monfort
Pushed. Thanks!
pgp4Qu7jnNrIK.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Sep 28, 2013 at 03:46:21PM +0100, Emil Velikov wrote:
> Use PKG_CHECK_MODULE over requesting the user to setup the
> option at configure time. Drop unused EXPAT_INCLUDE and add
> EXPAT_CFLAGS to all classic/dri and gallium/dri targets.
>
> Signed-off-by: Emil Velikov
> ---
> configure.ac
On Sat, Sep 28, 2013 at 03:46:18PM +0100, Emil Velikov wrote:
> The function xf86GetEntityInfo() retrieves the entity rather than
> doing any changes. Remove this no-op code.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Tom Stellard
> ---
> src/gallium/targets/r600/xorg/xorg.c| 3 --
On Fri, Oct 04, 2013 at 09:22:30PM +0200, Laurent Carlier wrote:
> http://llvm.org/viewvc/llvm-project?view=revision&revision=191922
Pushed, thanks!
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/g
On 07/10/13 12:05, Marek Olšák wrote:
> From: Marek Olšák
>
> which contains -Wl,-Bsymbolic. If I understand it correctly, it prevents
> symbols from clashing if multiple drivers are loaded at the same time.
A small side note,
This and the original commit handling the classic dri drivers, cause
On 07/10/13 14:21, Tom Stellard wrote:
> On Mon, Oct 07, 2013 at 01:52:35PM +0200, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> I wonder why we don't just append the flags in configure.ac. They have to be
>> used everywhere anyway.
>
> I'm not sure why either, but you could add this variable to
On Mon, Oct 07, 2013 at 01:05:15PM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
Reviewed-by: Tom Stellard
> ---
> configure.ac | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 559c9a3..6158c6e 100644
> --- a/configure.ac
> +
On Mon, Oct 07, 2013 at 01:52:35PM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> I wonder why we don't just append the flags in configure.ac. They have to be
> used everywhere anyway.
I'm not sure why either, but you could add this variable to
src/gallium/Automake.inc if you want to.
Either
From: Marek Olšák
I wonder why we don't just append the flags in configure.ac. They have to be
used everywhere anyway.
---
src/gallium/state_trackers/dri/drm/Makefile.am | 3 ++-
src/gallium/state_trackers/dri/sw/Makefile.am | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/s
From: Marek Olšák
I wonder why we don't just append the flags in configure.ac. They have to be
used everywhere anyway.
---
src/gallium/drivers/llvmpipe/Makefile.am | 3 ++-
src/gallium/drivers/softpipe/Makefile.am | 3 ++-
src/gallium/targets/dri-swrast/Makefile.am | 3 ++-
src/gallium/winsy
From: Marek Olšák
I wonder why we don't just append the flags in configure.ac. They have to be
used everywhere anyway.
---
src/gallium/drivers/r600/Makefile.am | 3 ++-
src/gallium/drivers/radeon/Makefile.am | 8 +---
src/gallium/drivers/radeonsi/Makefile.am | 4 +++-
From: Marek Olšák
---
configure.ac | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 559c9a3..6158c6e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1532,8 +1532,9 @@ AC_ARG_WITH([llvm-shared-libs],
[with_llvm_shared_libs=no])
AS_I
From: Marek Olšák
Undefined symbol references should cause a linker error.
All gallium drivers use this.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 9546163..559c9a3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1033,7
From: Marek Olšák
which contains -Wl,-Bsymbolic. If I understand it correctly, it prevents
symbols from clashing if multiple drivers are loaded at the same time.
---
src/gallium/targets/dri-freedreno/Makefile.am | 2 +-
src/gallium/targets/dri-i915/Makefile.am | 2 +-
src/gallium/targets/dr
https://bugs.freedesktop.org/show_bug.cgi?id=70123
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=70123
--- Comment #2 from Christian König ---
Created attachment 87229
--> https://bugs.freedesktop.org/attachment.cgi?id=87229&action=edit
Possible fix
Please try the attached patch, it might fix your issue.
--
You are receiving this mail because
Yes, but this is a separate issue I think. We fail safely, and it
doesn't matter for the common path when only PutBits is used.
That said it shouldn't be too hard to convert between YV12 and NV12 or
YUYV and UYVY. The chroma type is fixed for a given VdpVideoSurface so
it doesn't make sense to
Am 01.10.2013 21:06, schrieb Grigori Goronzy:
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 b
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
wrote:
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 s
Am 01.10.2013 21:12, schrieb Ilia Mirkin:
On Tue, Oct 1, 2013 at 3:06 PM, Grigori Goronzy wrote:
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
radeon_drm_cs_sync_flush doesn't seems to be save when it's called from
multiple threads but thought that this might be intentional.
Maybe we are running into that issue now that we are calling it more often.
Changing that should be trivial, going to attach a possible fix to the
bugreport in a
51 matches
Mail list logo
