https://bugs.freedesktop.org/show_bug.cgi?id=77102
Priority: medium
Bug ID: 77102
Assignee: mesa-dev@lists.freedesktop.org
Summary: gallium nouveau has no profile in vdpau and libva
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=77102
--- Comment #1 from Stefan Ringel m...@stefanringel.de ---
Created attachment 96974
-- https://bugs.freedesktop.org/attachment.cgi?id=96974action=edit
vdpainfo gdb
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=77102
--- Comment #3 from Stefan Ringel m...@stefanringel.de ---
Created attachment 96976
-- https://bugs.freedesktop.org/attachment.cgi?id=96976action=edit
vdpauinfo valgrind
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=77102
--- Comment #2 from Stefan Ringel m...@stefanringel.de ---
Created attachment 96975
-- https://bugs.freedesktop.org/attachment.cgi?id=96975action=edit
vainfo valgrind
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=77102
Ilia Mirkin imir...@alum.mit.edu changed:
What|Removed |Added
Status|NEW |RESOLVED
Hi Jon,
Sorry about this breakage. I assumed that the library extensions are handled
consistently across mesa. Seems like I was wrong.
Guessing that you meant to send this to the mesa-dev ?
On 06/04/14 15:59, Jon TURNEY wrote:
Partially revert bba9c28 configure: use LIB_EXT rather than
https://bugs.freedesktop.org/show_bug.cgi?id=77102
Stefan Ringel m...@stefanringel.de changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=77102
Ilia Mirkin imir...@alum.mit.edu changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop.
On Sat, Apr 5, 2014 at 5:07 AM, Emil Velikov emil.l.veli...@gmail.comwrote:
Hi all,
This is the final round cleaning up the exported symbols mayhem for
gallium.
IIRC the only place in mesa that needs some love is src/mapi.
Highlights:
- Drops __dri2ConfigOptions for both classic and
Am 05.04.2014 03:46, schrieb Emil Velikov:
Using export-symbols-regex is the least desirable method of restricting
the exported symbols, as is completely messes up with the symbol table.
radeon_drm_winsys_create is not needed, avoid exporting it.
Please add that anyway, we are going to need
Am 05.04.2014 11:47, schrieb Emil Velikov:
On 05/04/14 10:34, Christian König wrote:
Am 05.04.2014 03:46, schrieb Emil Velikov:
Using export-symbols-regex is the least desirable method of restricting
the exported symbols, as is completely messes up with the symbol table.
Why? As far as I can
Am 05.04.2014 11:16, schrieb Maarten Lankhorst:
op 05-04-14 03:46, Emil Velikov schreef:
Rather than having multiple (almost) identical version scripts use
a single one.
Cc: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Emil
Am 05.04.2014 03:46, schrieb Emil Velikov:
In the presence of LLVM the final library exports every symbol from
the llvm namespace. Resolve this by using a version script (w/o the
version/name tag).
Considering that there are only ~25 symbols, explicitly list them
to minimize the chances of
Am 05.04.2014 03:46, schrieb Emil Velikov:
Using export-symbols-regex is the least desirable method of restricting
the exported symbols, as is completely messes up with the symbol table.
Why? As far as I can tell it does exactly what it is supposed to do.
Christian.
Cc: Christian König
Am 05.04.2014 03:47, schrieb Emil Velikov:
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium/targets/r600/omx/Makefile.am | 8 +---
From: Chia-I Wu o...@lunarg.com
Given
mov vgrf7, vgrf9.xyxz
add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
add vgrf10.x, vgrf6.xyzw, vgrf7.
the last instruction would be wrongly changed to
add vgrf10.x, vgrf6.xyzw, vgrf9.
during copy propagation.
The issue is that when deciding if a
On 04/02/2014 01:04 AM, Chris Forbes wrote:
Previously, we would unpack the texels to floats using *_TO_FLOAT_TEX,
and then pack them into the desired format using FLOAT_TO_*. Unfortunately,
this isn't quite the inverse operation, and so some texel values would
end up off-by-one.
These
On 04/05/2014 12:33 AM, Ian Romanick wrote:
On 03/27/2014 11:45 PM, Tapani Pälli wrote:
Hi;
Patches implement the extension, no Piglit regressions and all the tests
for the extension pass (I've planned some more tests which are not yet
in though).
Changes shortly:
- opt_dead_code
On 04/05/2014 12:58 AM, Ian Romanick wrote:
On 04/04/2014 02:42 PM, Ian Romanick wrote:
On 03/27/2014 11:45 PM, Tapani Pälli wrote:
Patch adds a preprocessor define for the extension and stores
explicit location data for uniforms during AST-HIR conversion.
It also sets layout token to be
On 04/02/2014 01:05 AM, Chris Forbes wrote:
None of the other 3-component 16bpc formats are directly supported, so
they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
way makes texture views much more fiddly -- we don't want to have to do
crazy copying behind the scenes.
Yes, that will work -- will do.
On Mon, Apr 7, 2014 at 5:29 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 04/02/2014 01:05 AM, Chris Forbes wrote:
None of the other 3-component 16bpc formats are directly supported, so
they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
I'll move this patch after 7/30 to avoid things being temporarily broken.
On Thu, Apr 3, 2014 at 3:34 AM, Brian Paul bri...@vmware.com wrote:
On 04/02/2014 02:04 AM, Chris Forbes wrote:
These formats can be cast to others (with different component types or
sizes) via ARB_texture_view or
On 04/05/2014 01:18 AM, Ian Romanick wrote:
On 03/27/2014 11:45 PM, Tapani Pälli wrote:
Patch refactors the existing uniform processing so explicit locations
are taken in to account during variable processing. These locations
are temporarily stored in gl_uniform_storage before actual locations
23 matches
Mail list logo
