Use all zpass data for predication instead of the last block only.
Use query buffer as a ring instead of reusing the same area
for each new BeginQuery. All query buffer offsets are in bytes
to simplify offsets math.
---
src/gallium/drivers/r600/r600.h | 19 +++-
src/gallium/drivers
On Thu, Jun 23, 2011 at 7:08 PM, Brian Paul wrote:
>
> I'd like to overhaul the part of Mesa related to texture memory
> reading/writing.
>
> The basic idea would be to add two new driver functions:
>
> /**
> * Map a 2D slice of a texture image into user space.
> * (x,y,w,h) defines a region of
on gen6+, PIPE_CONTROL reported timestamp counter is a
64 bits value, toggles every 80 ns
Signed-off-by: Zou Nan hai
---
src/mesa/drivers/dri/i965/brw_queryobj.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/br
In a rare case of building gallium only, we need to
check if the required packages are available
libdrm_[intel|nouveau] - gallium[i915 i965|nouveau]
v2: r300g and r600g do not need libdrm_radeon
Signed-off-by: Emil Velikov
---
configure.ac |3 +++
1 files changed, 3 insertions(+), 0 deleti
On Thu, Jul 14, 2011 at 4:54 PM, Emil Velikov wrote:
> On Thu, 14 Jul 2011 21:40:13 +0100, Marek Olšák wrote:
>
>> r300g and r600g do not use libdrm_radeon. Only the classic drivers do.
>>
>> Marek
>
> There appears to be a dependency on "radeon_drm.h" in the winsys files
>
> ./src/gallium/driver
On Thu, 14 Jul 2011 21:40:13 +0100, Marek Olšák wrote:
r300g and r600g do not use libdrm_radeon. Only the classic drivers do.
Marek
There appears to be a dependency on "radeon_drm.h" in the winsys files
./src/gallium/drivers/r600/r600_buffer.c:#include "radeon_drm.h"
./src/gallium/winsys/r6
On Thu, Jul 14, 2011 at 4:35 PM, Emil Velikov wrote:
> In a rare case of building gallium only, we need to
> check if the required packages are available
>
> libdrm_[intel|radeon|nouveau] - gallium[i915 i965|r300 r600|nouveau]
r300g and r600g do not use libdrm_radeon anymore. Only the classic dr
r300g and r600g do not use libdrm_radeon. Only the classic drivers do.
Marek
On Thu, Jul 14, 2011 at 10:35 PM, Emil Velikov wrote:
> In a rare case of building gallium only, we need to
> check if the required packages are available
>
> libdrm_[intel|radeon|nouveau] - gallium[i915 i965|r300 r600|
In a rare case of building gallium only, we need to
check if the required packages are available
libdrm_[intel|radeon|nouveau] - gallium[i915 i965|r300 r600|nouveau]
Signed-off-by: Emil Velikov
---
configure.ac |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/configu
On Thu, Jul 14, 2011 at 4:03 PM, Emil Velikov wrote:
> Is it still possible to build radeon,r300,r600 without LIBDRM_RADEON?
You can, but only for UMS/DRI1 and I don't know how well tested that
is any more. KMS/DRI2 classic drivers require libdrm_radeon.
Alex
>
> Signed-off-by: Emil Velikov
>
Is it still possible to build radeon,r300,r600 without LIBDRM_RADEON?
Signed-off-by: Emil Velikov
---
configure.ac |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index c186240..d156979 100644
--- a/configure.ac
+++ b/configure.ac
@@ -10
On Thu, Jul 14, 2011 at 1:19 PM, Christian König
wrote:
> Yeah, I also thought about this. My overall feeling was to get it into
> VRAM first and then bring it into the form needed by the hardware with a
> shader if the need arise.
That's pretty much impossible since you can't use a shader to gen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2011 10:05 AM, Jose Fonseca wrote:
> Module: Mesa
> Branch: master
> Commit: 9a7f84d6b28e180ef79349b36de9a5d58a1e2dc9
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9a7f84d6b28e180ef79349b36de9a5d58a1e2dc9
>
> Author: José Fons
Am Donnerstag, den 14.07.2011, 15:36 + schrieb youne...@gmail.com:
> I wasn't going to bring this up until I had all the hardware decoding
> bits sorted out, however since you mention it, "vertex buffers" make
> no sense in a video decoding interface. You can't assume that a driver
> can provid
https://bugs.freedesktop.org/show_bug.cgi?id=39219
Ian Romanick changed:
What|Removed |Added
Component|GLU |GLX
CC|
2011/7/14 Brian Paul :
> On 07/13/2011 01:26 PM, Marcin Baczyński wrote:
>>
>> ---
>>
>> Without this patch CFLAGS=-fstrict-aliasing ./autogen.sh ... has no
>> effect,
>> as the flag is followed by -fno-strict-aliasing added by configure.
>>
>> configure.ac | 8
>> 1 files changed, 8
Christian König wrote:
Hello list,
I'm about to commit the attached patches, they add checks that the
correct development packages are installed before enabling the different
state trackers.
Don't know if this one is specific to my setup/options but -
./autogen.sh --prefix=/home/andy/Src/Xorg
On 07/13/2011 01:26 PM, Marcin Baczyński wrote:
---
Without this patch CFLAGS=-fstrict-aliasing ./autogen.sh ... has no effect,
as the flag is followed by -fno-strict-aliasing added by configure.
configure.ac |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a
On 07/13/2011 01:26 PM, Marcin Baczyński wrote:
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index ef9f4b2..28c8e2f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -89,7 +89,7 @@ if test "x$GCC" = xyes -a "x$CLANG" = xno;
On , Christian König wrote:
Am Donnerstag, den 14.07.2011, 15:04 +0200 schrieb Michel Dänzer:
> On Mit, 2011-07-13 at 16:28 -0600, Brian Paul wrote:
> > Silences many warnings about "type of bit-field 'field_select' is a
> > GCC extension".
> > ---
> > src/gallium/include/pipe/p_v
2011/7/14 Christian König :
> Hi Emeric,
>
> thanks for the tip, I've added "xorg-server" development files to the
> dependencies list and pushed it.
>
> I've just take a look over your VP8 code, looks quite good so far, just
> some side notes:
> 1.) regarding the picture parameter to decode_bitstr
2011/7/14 Christian König :
> Hello list,
>
> I'm about to commit the attached patches, they add checks that the
> correct development packages are installed before enabling the different
> state trackers.
>
> Since me and autoconf are in a fight for several years now please take a
> look and check
https://bugs.freedesktop.org/show_bug.cgi?id=39211
--- Comment #3 from Alexandre Demers 2011-07-14
07:49:45 PDT ---
confirmed to be fixed.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=39211
Christian König changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
May I suggest to fix that one also since there is a missing dependency
on d3dx state tracker?
https://bugs.freedesktop.org/show_bug.cgi?id=33938
Cheers,
--
Alexandre Demers
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesk
On 07/14/2011 07:28 AM, Christian König wrote:
Am Donnerstag, den 14.07.2011, 15:04 +0200 schrieb Michel Dänzer:
On Mit, 2011-07-13 at 16:28 -0600, Brian Paul wrote:
Silences many warnings about "type of bit-field ‘field_select’ is a
GCC extension".
---
src/gallium/include/pipe/p_video_state.
Hi Emeric,
thanks for the tip, I've added "xorg-server" development files to the
dependencies list and pushed it.
I've just take a look over your VP8 code, looks quite good so far, just
some side notes:
1.) regarding the picture parameter to decode_bitstream: Don't hack
around my bugs, just leave
Am Donnerstag, den 14.07.2011, 15:04 +0200 schrieb Michel Dänzer:
> On Mit, 2011-07-13 at 16:28 -0600, Brian Paul wrote:
> > Silences many warnings about "type of bit-field ‘field_select’ is a
> > GCC extension".
> > ---
> > src/gallium/include/pipe/p_video_state.h |8
> > 1 files ch
Hi Christian,
I don't know if that deserve a check in the autoconf, but the XvMC
state tracker requires this #include from the xorg
server development package.
Someone had the problem on the #mesa-devel channel, and could not get
mesa to build with --enable-xvmc because of it, so I guess this is a
On Mit, 2011-07-13 at 16:28 -0600, Brian Paul wrote:
> Silences many warnings about "type of bit-field ‘field_select’ is a
> GCC extension".
> ---
> src/gallium/include/pipe/p_video_state.h |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/include/p
On Thu, 14 Jul 2011 21:38:30 +0800, Zou Nan hai wrote:
> PIPE_CONTROL reported time stamp is a 64 bits value,
> toggles every 80ns.
The extension also exists on gen5, so you still need to support that.
pgpcFATf34Vbw.pgp
Description: PGP signature
Hello list,
I'm about to commit the attached patches, they add checks that the
correct development packages are installed before enabling the different
state trackers.
Since me and autoconf are in a fight for several years now please take a
look and check that I'm not doing anything stupid.
Chri
https://bugs.freedesktop.org/show_bug.cgi?id=39209
--- Comment #7 from Victor Tseng 2011-07-14 05:04:44 PDT ---
Okay, I found it DOES impact my Radeon HD 3300, too.
If I turn on "Loose Binding" option in fusion-icon, both computer have the same
problem (not properly rendering itself).
If I turn
> hello,
>
> It seems than configure do not check the presence of libvdpau-dev package
> when vdpau is enable.
> I had a build failed today because of missing vdpau.h, install libvdpau-dev
> package fix build error.
> (I had enable the vdpau build option)
>
> Someone can add the check the presen
https://bugs.freedesktop.org/show_bug.cgi?id=39209
--- Comment #6 from Henri Verbeet 2011-07-14 04:31:35 PDT
---
I think that's a r700 card, so changing evergreen_state.c probably won't do
much.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=39209
--- Comment #5 from Victor Tseng 2011-07-14 04:21:28 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > Created an attachment (id=49066)
View: https://bugs.freedesktop.org/attachment.cgi?id=49066
Review: https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=39209
--- Comment #4 from Victor Tseng 2011-07-14 04:15:54 PDT ---
(In reply to comment #3)
> Created an attachment (id=49066)
View: https://bugs.freedesktop.org/attachment.cgi?id=49066
Review: https://bugs.freedesktop.org/review?bug=39209&attachment
https://bugs.freedesktop.org/show_bug.cgi?id=39209
Victor Tseng changed:
What|Removed |Added
CC||pala...@gmail.com
--
Configure bugmail:
hello,
It seems than configure do not check the presence of libvdpau-dev package
when vdpau is enable.
I had a build failed today because of missing vdpau.h, install libvdpau-dev
package fix build error.
(I had enable the vdpau build option)
Someone can add the check the presence of libvdpau-dev
https://bugs.freedesktop.org/show_bug.cgi?id=39219
Padfoot changed:
What|Removed |Added
CC||padf...@exemail.com.au
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=39219
Summary: libgl conflict with xbmc causes lock up on xbmc exit
Product: Mesa
Version: 7.10
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=39210
Christian König changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=39210
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
Priority|medium
https://bugs.freedesktop.org/show_bug.cgi?id=39211
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
Severity|normal
> The forward references to video enum types in p_context.h causes
> a massive number of compiler warnings (ISO C forbids forward references
> to ?enum? types).
>
> By putting the new video enums in a separate header that can be included
> by p_context.h and p_screen.h we can avoid this.
Akk for p
45 matches
Mail list logo
