On 07.02.2014 23:25, Dave Airlie wrote:
>>> Doh, yes because GL has ARB_texture_gather then has stuff hidden away
>>> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should
>>> do.
>>>
>>> So I've reposted with the component selection in src1 now.
>> Hmm seems a bit excessive
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 byte
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 +++
src/gallium/dr
--enable-gallium-llvm is required by radeonsi. Currently we
check only for LLVM_VERSION_INT which is 0, whenever gallium-llvm
is disabled explicitly.
./configure --with-gallium-drivers=r600,radeonsi --disable-gallium-llvm
Signed-off-by: Emil Velikov
---
configure.ac | 11 +++
1 file cha
One step towards vdpau-interop to work.
Signed-off-by: Emil Velikov
---
src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys
Hello list,
Continuing with another not so interesting area of mesa - cleaning up
the exported symbols and adding make check tests.
Note: Most of these patches are rather dull and may cause boredom or
sleepiness :-)
Before proceeding make sure that with-llvm-shared-libs is set, otherwise
the mod
With all the symbols resolved, there is no need to use
version-script to restrict exported symbols.
Signed-off-by: Emil Velikov
---
src/gallium/targets/pipe-loader/Makefile.am | 2 --
src/gallium/targets/pipe-loader/pipe.link | 3 ---
2 files changed, 5 deletions(-)
delete mode 100644 src/gal
dri targets should export the following
- __driDriverExtensions
- __dri2ConfigOptions
and
- *winsys_create > for gl-vdpau interop
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 1 -
src/gallium/targets/dri-i915/Makefile.am | 5 +
src/gallium/targets/d
Symbol is internal and was never meant to be exported.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/gbm/Makefile.am | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/gbm/Makefile.am
b/src/gallium/state_trackers/gbm/Makefile.am
index
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/pipe-loader/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/pipe-loader/Makefile.am
b/src/gallium/auxiliary/pipe-loader/Makefile.am
index 8e4d034..74a61a3 100644
--- a/src/gallium/auxiliary/pipe-loader/Ma
This symbol is internal and was never part of the API.
Unused by any of the gbm backends, it makes sense to
simply not export it.
Cc: Kristian Høgsberg
Signed-off-by: Emil Velikov
---
src/gbm/main/gbm.c| 2 +-
src/gbm/main/gbmint.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
d
Signed-off-by: Emil Velikov
---
src/gallium/targets/egl-static/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/targets/egl-static/Makefile.am
b/src/gallium/targets/egl-static/Makefile.am
index 73bb795..7559bcd 100644
--- a/src/gallium/targets/egl-static/Makefile.am
++
Most places in mesa requires explicit VISIBILITY_CFLAGS causing
some headache when introducing new build components and managing
existing ones. Move to inconditionally hide all symbols and make
sure we explicitly set the ones that need to be public.
XXX: The following needs to be checked/tested
s
Initial step of cleaning the exported symbols from targets/omx
- Mark omx_component_library_Setup as public
- Drop export-symbols-regex
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/omx/Makefile.am | 1 +
src/gallium/state_trackers/omx/entrypoint.h | 2 +-
src/gallium/targets/
Signed-off-by: Emil Velikov
---
src/gallium/targets/omx-symbols-check| 13 +
src/gallium/targets/r600/omx/Makefile.am | 6 ++
src/gallium/targets/radeonsi/omx/Makefile.am | 6 ++
3 files changed, 25 insertions(+)
create mode 100755 src/gallium/targets/omx-symbol
Signed-off-by: Emil Velikov
---
src/egl/wayland/wayland-egl/Makefile.am | 2 ++
src/egl/wayland/wayland-egl/wayland-egl-symbols-check | 16
2 files changed, 18 insertions(+)
create mode 100755 src/egl/wayland/wayland-egl/wayland-egl-symbols-check
diff --git a/src
There is no cpp files during the build process, thus we
can safely drop the unused cxxflags.
Signed-off-by: Emil Velikov
---
src/mesa/drivers/osmesa/Makefile.am | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/mesa/drivers/osmesa/Makefile.am
b/src/mesa/drivers/osmesa/Makefile.am
index d
Drop the use of -export-symbols-regex now that xvmc drivers/backends
export only the required functions. Add a test to capture future
problems via make check.
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 1 -
src/gallium/targets/r600/xvmc/Makefile.am| 6 ++
Currently the library exports every symbol imaginable,
rather than the ones defined by the API.
Note: This may cause issues for libraries that are linking
agaist libgbm's internals.
Cc: Kristian Høgsberg
Signed-off-by: Emil Velikov
---
src/gbm/Makefile.am | 3 ++-
1 file changed, 2 insertions(
Signed-off-by: Emil Velikov
---
src/gallium/targets/gbm/Makefile.am | 2 ++
src/gallium/targets/gbm/gallium-gbm-symbols-check | 13 +
src/gbm/Makefile.am | 2 ++
src/gbm/gbm-symbols-check | 33 +++
4
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/vdpau/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/Makefile.am
b/src/gallium/state_trackers/vdpau/Makefile.am
index a2fa366..a74b5bf 100644
--- a/src/gallium/state_trackers/vdpau/Makefi
Signed-off-by: Emil Velikov
---
src/gallium/targets/egl-static/Makefile.am | 2 --
src/gallium/targets/egl-static/egl.link| 3 ---
2 files changed, 5 deletions(-)
delete mode 100644 src/gallium/targets/egl-static/egl.link
diff --git a/src/gallium/targets/egl-static/Makefile.am
b/src/galliu
Add VISIBILITY_CFLAGS to automake build, so that
only required symbols are exported.
Signed-off-by: Emil Velikov
---
src/gallium/targets/gbm/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/targets/gbm/Makefile.am
b/src/gallium/targets/gbm/Makefile.am
index 4299d07..5
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/egl/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/egl/Makefile.am
b/src/gallium/state_trackers/egl/Makefile.am
index bad14fe..9c00f06 100644
--- a/src/gallium/state_trackers/egl/Makefile.am
++
The function pointer is retrieved via VdpGetProcAddress just
like all the other vdpau functions and should not be exported.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/vdpau/device.c| 2 +-
src/gallium/state_trackers/vdpau/vdpau_private.h | 4 +++-
2 files changed, 4 inser
Use the c++ visibility flags when building cpp files.
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/clover/Makefile.am | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/clover/Makefile.am
b/src/gallium/state_trackers/clover/Makefil
Signed-off-by: Emil Velikov
---
src/egl/main/Makefile.am | 2 +
src/egl/main/egl-symbols-check | 109 +
2 files changed, 111 insertions(+)
create mode 100755 src/egl/main/egl-symbols-check
diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makef
And drop the obsolete export-symbol-regex from the linker.
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 1 -
src/gallium/targets/r600/vdpau/Makefile.am | 6 ++
src/gallium/targets/radeonsi/vdpau/Makefile.am | 6 ++
src/gallium/targets/vdpau-nouv
I didn't think to try this. Where is the address folding happening?
On 02/07/2014 07:46 AM, Tom Stellard wrote:
From: Tom Stellard
---
lib/Target/R600/AMDGPUISelDAGToDAG.cpp | 48 ++
lib/Target/R600/SIISelLowering.cpp | 29
lib/Targe
Consider a multithreaded program with two contexts A and B, and the
following scenario:
1. Context A calls initialize(), which allocates mem_ctx and starts
building built-ins.
2. Context B calls initialize(), which sees mem_ctx != NULL and assumes
everything is already set up. It returns.
3
On 02/08/2014 02:41 AM, Matt Turner wrote:
On Fri, Feb 7, 2014 at 10:22 PM, Andrew Guertin wrote:
Hi,
I updated mesa and started getting some bad behavior in League of Legends
(played through wine). After starting a game, upon hovering any of the skill
buttons, instead of an info tooltip appea
Hi,
I updated mesa and started getting some bad behavior in League of
Legends (played through wine). After starting a game, upon hovering any
of the skill buttons, instead of an info tooltip appearing, the whole
screen is covered in grey. Some other problems are visible too, like the
options
On Thursday 30 January 2014, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/main/api_validate.c | 2 +-
> src/mesa/main/bufferobj.c | 12
> src/mesa/main/bufferobj.h | 8
> src/mesa/main/drawpix.c | 4 ++--
> src/mesa/main/pbo.c | 4 +
On 02/07/2014 04:43 PM, Brian Paul wrote:
> We don't need to allocate all the state related to GL_ARB_debug_output
> until some aspect of that extension is actually needed.
>
> The sizeof(gl_debug_state) is huge (~285KB on 64-bit systems), not even
> counting the 54(!) hash tables and lists that i
The purpose of this version script looks to be related to static
builds, but in your cover letter you said you were building with
shared LLVM libraries. Does this affect static builds?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists
Same question as before about static builds.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Feb 8, 2014 at 8:04 AM, Emil Velikov wrote:
> dri targets should export the following
> - __driDriverExtensions
> - __dri2ConfigOptions
> and
> - *winsys_create > for gl-vdpau interop
>
> Signed-off-by: Emil Velikov
> ---
> src/gallium/Automake.inc | 1 -
> src/ga
On Sat, Feb 8, 2014 at 8:04 AM, Emil Velikov wrote:
> Most places in mesa requires explicit VISIBILITY_CFLAGS causing
> some headache when introducing new build components and managing
> existing ones. Move to inconditionally hide all symbols and make
> sure we explicitly set the ones that need to
On Sat, Feb 8, 2014 at 8:03 AM, Emil Velikov wrote:
>
I sent questions about patches 2, 12, 16 (which also applies to 17,
and maybe some others). I don't think we should do patch 20, and I
barely know what OpenMAX is for 21 and 22.
1, 3-11, 13-19 are (assuming in and out of tree builds work)
Re
https://bugs.freedesktop.org/show_bug.cgi?id=74717
Andreas Boll changed:
What|Removed |Added
CC||andreas.boll@gmail.com,
https://bugs.freedesktop.org/show_bug.cgi?id=74723
Priority: medium
Bug ID: 74723
Assignee: mesa-dev@lists.freedesktop.org
Summary: main/shaderapi.c:407: detach_shader: Assertion
`shProg->Shaders[j]->Type == 0x8B31 ||
On 08/02/14 17:53, Matt Turner wrote:
> The purpose of this version script looks to be related to static
> builds, but in your cover letter you said you were building with
> shared LLVM libraries. Does this affect static builds?
>
Unfortunately it does. For static builds the version script preven
On 08/02/14 19:13, Matt Turner wrote:
> On Sat, Feb 8, 2014 at 8:04 AM, Emil Velikov wrote:
>> dri targets should export the following
>> - __driDriverExtensions
>> - __dri2ConfigOptions
>> and
>> - *winsys_create > for gl-vdpau interop
>>
>> Signed-off-by: Emil Velikov
>> ---
>> src/gallium/
On 08/02/14 19:22, Matt Turner wrote:
> On Sat, Feb 8, 2014 at 8:04 AM, Emil Velikov wrote:
>> Most places in mesa requires explicit VISIBILITY_CFLAGS causing
>> some headache when introducing new build components and managing
>> existing ones. Move to inconditionally hide all symbols and make
>>
Apparently some players are ill-prepared for us claiming that a decoder
exists only to have creating it fail, and express this poor preparation
with crashes (e.g. flash). Check that firmware is there to increase the
chances of there being a high correlation between reported capabilities
and ability
On 08/02/14 19:24, Matt Turner wrote:
> On Sat, Feb 8, 2014 at 8:03 AM, Emil Velikov wrote:
>>
>
> I sent questions about patches 2, 12, 16 (which also applies to 17,
> and maybe some others). I don't think we should do patch 20, and I
> barely know what OpenMAX is for 21 and 22.
>
> 1, 3-11, 13
https://bugs.freedesktop.org/show_bug.cgi?id=74723
--- Comment #1 from Andreas Boll ---
Created attachment 93675
--> https://bugs.freedesktop.org/attachment.cgi?id=93675&action=edit
bt full
--
You are receiving this mail because:
You are the assignee for the bug.
_
Candidate for 10.1 ?
2014-02-08 14:02 GMT+01:00 Grigori Goronzy :
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=74723
--- Comment #2 from Brian Paul ---
Created attachment 93676
--> https://bugs.freedesktop.org/attachment.cgi?id=93676&action=edit
update assertion for GS
Can you try this patch?
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=74723
--- Comment #3 from Andreas Boll ---
Tested-by: Andreas Boll
Candidate for stable?
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-d
https://bugs.freedesktop.org/show_bug.cgi?id=74723
--- Comment #4 from Brian Paul ---
(In reply to comment #3)
> Tested-by: Andreas Boll
>
> Candidate for stable?
>
> Thanks!
Yes, I'll tag it for 10.0 and 10.1
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=74723
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Please document the new caps in gallium/docs/../screen.rst.
Thank you.
Marek
On Sat, Feb 8, 2014 at 2:02 PM, Grigori Goronzy wrote:
> v2: adjust limits for radeonsi and llvmpipe
> ---
> src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
> src/gallium/drivers/i915/i915_screen.c
https://bugs.freedesktop.org/show_bug.cgi?id=74717
--- Comment #2 from Török Edwin ---
(In reply to comment #1)
> I have replayed your trace and I get the following failing assertion. (mesa
> is compiled with --enable-debug)
>
> glretrace: ../../src/glsl/ir.cpp:170:
> ir_assignment::ir_assignmen
https://bugs.freedesktop.org/show_bug.cgi?id=74727
Priority: medium
Bug ID: 74727
Assignee: mesa-dev@lists.freedesktop.org
Summary: Mesa 10.1: doesn't build with DRI3 enabled
Severity: normal
Classification: Unclassified
OS:
From: Rob Clark
This lets multiple gallium drivers use XA.
Signed-off-by: Rob Clark
---
configure.ac | 8 ++--
src/gallium/state_trackers/xa/Makefile.am | 11 -
src/gallium/state_trackers/xa/xa_priv.h | 1 +
src/gallium/state_trackers/xa/xa_trac
From: Rob Clark
Now that the rendering corruption issues from the very early days of
a3xx gallium are solved it is time to return to freedreno XA support,
so that presentation blit for windowed apps (and post-sub-buffer) !=
stall + memcpy(). With basic XA working now in xf86-video-freedreno,
it
From: Rob Clark
Build two versions of pipe-loader, with only the client version linking
in x11 client side dependencies. This will allow the XA state tracker
to use pipe-loader.
Signed-off-by: Rob Clark
---
configure.ac | 11 +--
src/gallium/auxil
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/targets/pipe-loader/Makefile.am | 16
src/gallium/targets/pipe-loader/pipe_msm.c | 20
2 files changed, 36 insertions(+)
create mode 100644 src/gallium/targets/pipe-loader/pipe_msm.c
diff --git a/s
59 matches
Mail list logo
