2011/5/5 Alex Deucher :
> 2011/5/5 Mathias Fröhlich :
>>
>> Hi all,
>>
>> On Thursday, May 05, 2011 04:32:03 you wrote:
>>> Okay my guess at the problem is that:
>>>
>>> the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
>>> on the base in the CB being the same as the texture BASE
Andy Furniss wrote:
There has been a regression though -
[g3dvl] remove resource_format workaround
causes quite bad artifacts on newmobcal.
I can get rid of the new artifacts for xvmc with the patch below.
ffmpeg12vdpau shows the same "new" artifacts, but is not fixed by this.
diff --git a/
https://bugs.freedesktop.org/show_bug.cgi?id=36792
--- Comment #1 from Alan Swanson 2011-05-05 05:27:51 PDT ---
Actually it's LLVM itself that causes linking to static libraries via
llvm-config even when built with enable shared due to LLVM bug 6823.
http://llvm.org/bugs/show_bug.cgi?id=6823
--
On Wed, 4 May 2011 18:21:20 -0700, Jesse Barnes
wrote:
> On Thu, 5 May 2011 11:17:02 +1000
> Dave Airlie wrote:
>
> > So I wasn't watching and glproto broke its interface, and I think its bad.
> >
> > Why?
> >
> > You can no longer bisect things across this point without now moving
> > glpro
https://bugs.freedesktop.org/show_bug.cgi?id=36307
Robert Hooker (Sarvatt) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36307
--- Comment #2 from d...@tzib.net 2011-05-05 08:24:18 PDT ---
Thanks for the fix :)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
On Wed, 4 May 2011 21:29:23 -0700
Jeremy Huddleston wrote:
> Yeah... so considering the comments in mesa-dev earlier today, I was really
> surprised to see that glproto and dri2proto were tagged today. I think we
> need to brownbag retract and rethink this.
Damnit; right when Dave mentioned t
Why is sbc a 32bit field in xGLXBufferSwapComplete2 and
xDRI2BufferSwapComplete2 when it is a 64bit field in GLXBufferSwapComplete?
The hunk at the bottom will result in casting a 64bit int to a 32bit int. If
you're going to change this, shouldn't you also change GLXBufferSwapComplete,
DRI2Swa
On Thu, 5 May 2011 10:07:24 -0700
Jeremy Huddleston wrote:
> Why is sbc a 32bit field in xGLXBufferSwapComplete2 and
> xDRI2BufferSwapComplete2 when it is a 64bit field in GLXBufferSwapComplete?
>
> The hunk at the bottom will result in casting a 64bit int to a 32bit int. If
> you're going to
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #5 from Iaroslav 2011-05-05 10:47:10 PDT ---
Created an attachment (id=46368)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46368)
llvm 3.0 svn + r300g
llvm 3.0 svn + r300g with
GALLIVM_DEBUG=tgsi,ir,asm
--
Configure bugmail
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #6 from Iaroslav 2011-05-05 10:51:31 PDT ---
Created an attachment (id=46369)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46369)
llvm 3.0 svn + swrast
llvm 3.0 svn + swrast
with GALLIVM_DEBUG=tgsi,ir,asm
--
Configure bugma
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #7 from Iaroslav 2011-05-05 12:13:29 PDT ---
Created an attachment (id=46371)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46371)
llvm28-r300.log
with GALLIVM_DEBUG=tgsi,ir,asm game crash before the menu, without
GALLIVM_DEB
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #8 from Iaroslav 2011-05-05 12:14:40 PDT ---
Created an attachment (id=46372)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46372)
llvm28-swrast
with GALLIVM_DEBUG=tgsi,ir,asm game crash before the menu, without
GALLIVM_DEBUG
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #9 from Iaroslav 2011-05-05 12:17:52 PDT ---
r300g + llvm 3.0 + UrbanTerror
Program received signal SIGSEGV, Segmentation fault.
0xa40cd27c in ?? ()
(gdb) bt
#0 0xa40cd27c in ?? ()
#1 0xa5cd1211 in llvm_pipeline_generic (middle=0x8
https://bugs.freedesktop.org/show_bug.cgi?id=36738
--- Comment #10 from Iaroslav 2011-05-05 12:25:08 PDT ---
Created an attachment (id=46373)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46373)
llvm28-r300 with GALLIVM_DEBUG=tgsi,ir
with GALLIVM_DEBUG=tgsi,ir all work
--
Configure bugm
This set is compatible with existing code bases since it adds a new
struct to the glx and dri2 proto files instead of renaming existing
fields.
New clients with old servers will see larger, but still broken, SBC
values. Old clients with new servers will see the same bad values they
see today. An
Just add a new struct to remain compatible with existing code.
Signed-off-by: Jesse Barnes
diff --git a/configure.ac b/configure.ac
index a3047e4..a6c301c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([GLProto], [1.4.13],
[https://bugs.freedesktop.org/
Just add a new struct to remain compatible with existing code.
Signed-off-by: Jesse Barnes
diff --git a/configure.ac b/configure.ac
index 9505f56..297be0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([DRI2Proto], [2.4],
[https://bugs.freedesktop.org/e
Use the new swap event type so we get valid SBC values.
Signed-off-by: Jesse Barnes
diff --git a/configure.ac b/configure.ac
index 54d9c29..fb38a4e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,8 +21,8 @@ dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.24
LIBDRM_RADEON_REQUIRE
Use the new event types so we can pass a valid SBC value to clients.
Fix up the completion calls to use CARD32 instead of CARD64 to match
the new field size.
Signed-off-by: Jesse Barnes
diff --git a/configure.ac b/configure.ac
index 6eb780c..3e0ed5d 100644
--- a/configure.ac
+++ b/configure.ac
@
On Thu, 5 May 2011 12:38:24 -0700
Jesse Barnes wrote:
> This set is compatible with existing code bases since it adds a new
> struct to the glx and dri2 proto files instead of renaming existing
> fields.
>
> New clients with old servers will see larger, but still broken, SBC
> values. Old clien
On Thu, 05 May 2011 12:59:50 -0700
Jeremy Huddleston wrote:
> For *proto/mesa:
> Reviewed-by: Jeremy Huddleston
Thanks.
> For xserver:
> This looks incomplete. You also need to update swap_count in DRI2DrawableRec
> to be CARD32.
That value is used in other places that actually preserve the
On Thu, 05 May 2011 13:17:13 -0700
Jeremy Huddleston wrote:
>
> On May 5, 2011, at 1:09 PM, Jesse Barnes wrote:
>
> > On Thu, 05 May 2011 12:59:50 -0700
> > Jeremy Huddleston wrote:
> >
> >> For *proto/mesa:
> >> Reviewed-by: Jeremy Huddleston
> >
> > Thanks.
> >
> >> For xserver:
> >> Thi
The following changes since commit f60235e73a5260f92630ce472e06d8c5c00414fb:
r600g: Match alpha ref precision to color format precision. (2011-05-05
21:00:38 +0200)
are available in the git repository at:
git://github.com/mslusarz/mesa.git gitsha1
Marcin Slusarz (2):
mesa: don't touch
Reviewed-by: Dan Nicholson
Reviewed-by: Ian Romanick
---
bin/extract_git_sha1 | 10 --
src/mesa/main/.gitignore |1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1
index e6e6731..5e635d4 100755
--- a/bin/extract_git_s
Reviewed-by: Dan Nicholson
Reviewed-by: Ian Romanick
---
bin/extract_git_sha1 |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1
index 5e635d4..8283870 100755
--- a/bin/extract_git_sha1
+++ b/bin/extract_git_sha1
@@ -3,6 +3,10
On Thu, 05 May 2011 13:36:40 -0700
Jeremy Huddleston wrote:
> >> Yes, I realize that there are some areas that use 64bit for sbc. Do we
> >> really need 64bits for this? If so, how do we properly to communicate the
> >> 64bit value between server/client? Currently, your changes result in an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/05/2011 01:37 PM, Marcin Slusarz wrote:
> Reviewed-by: Dan Nicholson
> Reviewed-by: Ian Romanick
I pushed both patches to Mesa master. Thanks.
> ---
> bin/extract_git_sha1 | 10 --
> src/mesa/main/.gitignore |1 +
> 2 file
> >if (swap_complete) {
> >if (pPriv->swap_count > 0x)
> >ErrorF("something appropriate");
> >swap_complete(client, swap_data, type, ust, frame,
> > (CARD32)pPriv->swap_count);
> >}
>
> Yeah, it's annoying. How about I leave out the error message and h
Am Donnerstag, den 05.05.2011, 12:11 +0100 schrieb Andy Furniss:
> Andy Furniss wrote:
> > There has been a regression though -
> >
> > [g3dvl] remove resource_format workaround
> >
> > causes quite bad artifacts on newmobcal.
>
> I can get rid of the new artifacts for xvmc with the patch below.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/05/2011 01:25 PM, Jesse Barnes wrote:
> On Thu, 05 May 2011 13:17:13 -0700
> Jeremy Huddleston wrote:
>>
>> Yes, I realize that there are some areas that use 64bit for sbc. Do we
>> really need 64bits for this? If so, how do we properly to co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/05/2011 12:38 PM, Jesse Barnes wrote:
> This set is compatible with existing code bases since it adds a new
> struct to the glx and dri2 proto files instead of renaming existing
> fields.
>
> New clients with old servers will see larger, but sti
On Thu, 05 May 2011 14:15:33 -0700
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/05/2011 12:38 PM, Jesse Barnes wrote:
> > This set is compatible with existing code bases since it adds a new
> > struct to the glx and dri2 proto files instead of renaming existing
2011/5/5 Christian König :
> Am Donnerstag, den 05.05.2011, 12:11 +0100 schrieb Andy Furniss:
>> Andy Furniss wrote:
>> > There has been a regression though -
>> >
>> > [g3dvl] remove resource_format workaround
>> >
>> > causes quite bad artifacts on newmobcal.
>>
>> I can get rid of the new artifa
We just prefix the $CLANG environment variable in configure.ac with acv_mesa_
Found by: tinderbox
Signed-off-by: Jeremy Huddleston
---
configure.ac |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 54d9c29..f3f0fda 100644
--- a/con
On May 5, 2011 5:10pm, Christian König wrote:
I'm currently focusing more on the variable length decoding part of the
vdpau mpeg2, by the way: How is well does this work on your hardware?
Regards,
Christian.
I have a somewhat working VLD implementation that I haven't had time to go
2011/5/5 Alex Deucher :
> 2011/5/5 Alex Deucher :
>> 2011/5/5 Mathias Fröhlich :
>>>
>>> Hi all,
>>>
>>> On Thursday, May 05, 2011 04:32:03 you wrote:
Okay my guess at the problem is that:
the CP tracks coherency but the SURFACE_BASE_UPDATE stuff might rely
on the base in the CB
Christian König wrote:
The problem is more complicated than this, using a signed buffer format
is just a workaround, the real solution is to implement blender clamping
in r600g. You could try this (temporary) patch until I figured out how
to do this correctly on all supported hardware:
--- a/sr
A new patch is attached.
Marek
On Tue, May 3, 2011 at 11:21 PM, Brian Paul wrote:
> On 05/03/2011 01:24 PM, Brian Paul wrote:
>>
>> On 05/03/2011 07:55 AM, Marek Olšák wrote:
>>>
>>> ---
>>> src/mesa/main/extensions.c | 1 +
>>> src/mesa/main/mtypes.h | 2 ++
>>> src/mesa/main/texobj
A new patch is attached.
Marek
On Tue, May 3, 2011 at 9:31 PM, Brian Paul wrote:
> On 05/03/2011 11:55 AM, Roland Scheidegger wrote:
>>
>> Am 03.05.2011 15:55, schrieb Marek Olšák:
>>>
>>> diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
>>> b/src/mesa/state_tracker/st_atom_rasterizer.c
The DRI driver itself might not have version 3 of the
DRI2 flush extension, in which case this would've
pointed to out of bounds memory...
---
src/glx/dri2_glx.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index ff48c79..179b
Copied the implementation from dri2_glx.c.
---
src/glx/drisw_glx.c | 51 ---
1 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index c5b1791..81fd188 100644
--- a/src/glx/drisw_glx.c
+++ b/src
Copied the implementation from dri2_glx.c.
---
Sorry, accidentally sent an old version that didn't apply and was
missing the release() code that got added between then and now. This
one should work.
src/glx/drisw_glx.c | 77 +--
1 files changed, 7
Now if a software DRI driver advertises it, we can use it
in direct-rendering contexts--without this, only the server
took advantage of it for indirect contexts.
This follows up on these commits:
8d789be03430b80e0ba2fef19d56dd0b8e699ea2
c14b4371ed58859d264b7b2581cfedc9cfd8401f
2b64886c817ffa2d
2011/4/27 Christian König
> Regarding the not working idct on nvidia hardware I would guess that we
> use something that the driver currently doesn't supports, like multiple
> render targets, disabled opengl rasterisation rules, unsupported
> intermediate buffer format or something else.
>
Hi Ch
On May 5, 2011, at 1:09 PM, Jesse Barnes wrote:
> On Thu, 05 May 2011 12:59:50 -0700
> Jeremy Huddleston wrote:
>
>> For *proto/mesa:
>> Reviewed-by: Jeremy Huddleston
>
> Thanks.
>
>> For xserver:
>> This looks incomplete. You also need to update swap_count in
>> DRI2DrawableRec to be CAR
>> Yes, I realize that there are some areas that use 64bit for sbc. Do we
>> really need 64bits for this? If so, how do we properly to communicate the
>> 64bit value between server/client? Currently, your changes result in an
>> implicit cast from 64bit to 32bits in DRI2SwapComplete which wil
For *proto/mesa:
Reviewed-by: Jeremy Huddleston
For xserver:
This looks incomplete. You also need to update swap_count in DRI2DrawableRec
to be CARD32.
On May 5, 2011, at 12:45 PM, Jesse Barnes wrote:
> Use the new event types so we can pass a valid SBC value to clients.
> Fix up the complet
48 matches
Mail list logo
