https://bugs.freedesktop.org/show_bug.cgi?id=37476
--- Comment #4 from Dave Airlie 2011-06-14 23:58:39
PDT ---
Hi Mike,
you might have noticed I pushed something that worked, then found this patch,
which I preferred to mine, so I fixed up the code with your authorship on a few
patches derived f
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Karl Tomlinson changed:
What|Removed |Added
CC||bugs.freedesk...@karlt.net
--- Comment
There will be a little bit of thrashing of the program cache BO as the
cache warms up, but once the application is in steady state, this
reduces relocations on gen5 and later.
On my T420 laptop, cairogl firefox-talos-gfx performance improves 2.6%
+/- 1.3% (n=6). No statistically significant perfo
This was debug code from the initial import of the driver. No
statistically significant performance difference on cairo-gl or
nexuiz (n=6).
---
src/mesa/drivers/dri/i965/brw_vtbl.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
Ok, 1e16c34c5c86690b26739fbad82617768b1bd837 should fix the warnings for those
still using compilers based in the 1980's ;p
--Jeremy
On Jun 14, 2011, at 5:19 PM, Brian Paul wrote:
> Still no go. You need to move the snprintf() calls after the variable
> declarations.
>
> -Brian
>
> On 06/14
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Tony Mechelynck changed:
What|Removed |Added
CC||antoine.mechely...@gmail.co
Still no go. You need to move the snprintf() calls after the variable
declarations.
-Brian
On 06/14/2011 01:33 PM, Jeremy Huddleston wrote:
Hi Brian,
Please give this change a try. It should clear up the gcc -pedantic warnings
and also replaces the NULL entries with noops since that seems
https://bugs.freedesktop.org/show_bug.cgi?id=38320
Brian Paul changed:
What|Removed |Added
Product|Mesa|freedesktop.org
Component|Other
When emitting either a hiz or stencil buffer, the 'separate stencil
enable' and 'hiz enable' bits are set in 3DSTATE_DEPTH_BUFFER. Therefore
we must emit both 3DSTATE_HIER_DEPTH_BUFFER and 3DSTATE_STENCIL_BUFFER.
Even if there is no stencil buffer, 3DSTATE_STENCIL_BUFFER must be
emitted; failure t
https://bugs.freedesktop.org/show_bug.cgi?id=38320
--- Comment #2 from Paul Berry 2011-06-14 15:25:07
PDT ---
Created an attachment (id=47972)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47972)
SSH key
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=38320
--- Comment #1 from Paul Berry 2011-06-14 15:23:37
PDT ---
Created an attachment (id=47971)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47971)
GPG key
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=38320
Summary: Account Request for Paul Berry
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Co
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Ian Romanick changed:
What|Removed |Added
CC||cwo...@cworth.org,
|
Removing this flag seems right to me, but always building the egl
state tracker when gallium and egl is enabled not.
So when --with-state-trackers is also removed, we'd need a new
--with-egl-drivers=auto|gallium,dri2,glx or so.
The usecase is that you could choose to use st/dri together with
egl_d
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Robert Kaiser changed:
What|Removed |Added
CC||ka...@kairo.at
--
Configure bugmail: ht
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #5 from Benoit Jacob 2011-06-14 13:28:02 PDT
---
Also, I forgot something in my pseudocode: we call glCheckFramebufferStatus
right before the glGetIntegerv call. This shouldn't make any difference, but it
could hit a bug whereby glCh
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #4 from Benoit Jacob 2011-06-14 13:17:06 PDT
---
> Questions:
I don't know the answers to these questions. I'll check if the user who
reported this is interested in further debugging this and I'll make him a
build.
>From your persp
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Chad Versace changed:
What|Removed |Added
CC||c...@chad-versace.us
--
Configure bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Ian Romanick changed:
What|Removed |Added
Keywords||NEEDINFO
--- Comment #3 from Ian Romanick
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #2 from Benoit Jacob 2011-06-14 12:37:44 PDT
---
...and, in case you wonder what LOCAL_GL_FRAMEBUFFER_BINDING is, it's just the
same as GL_FRAMEBUFFER_BINDING, i forgot to edit that part. It's defined as
0x8CA6 which is the correct v
https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #1 from Benoit Jacob 2011-06-14 12:35:21 PDT
---
Here's some info from the user who reported the bug to us:
OS: openSUSE Linux 11.4 (version: Final, architecture: x86_64)
Software packages (among others, of course):
xorg-x11-driver
Hi Brian,
Please give this change a try. It should clear up the gcc -pedantic warnings
and also replaces the NULL entries with noops since that seems to be done in
other tables as well (eg: indirect_init.c).
Thanks,
Jeremy
diff --git a/src/mapi/glapi/gen/gl_gentable.py
b/src/mapi/glapi/gen/g
https://bugs.freedesktop.org/show_bug.cgi?id=38312
Summary: Swrast doesn't really know whether a Framebuffer
object is bound
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
S
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?
On Die, 2011-06-07 at 10:17 +0200, Thomas Hellstrom wrote:
> On 06/06/2011 05:20 PM, James Jones wrote:
> > On 6/6/11 2:09 AM, "Thomas Hellstrom" wrote:
> >
> >
> >> Hi!
> >>
> >> While trying to improve the vmwgfx X driver to better cope with OpenGL
> >> compositors, I noticed that compiz ne
On Die, 2011-06-14 at 09:45 -0700, Jose Fonseca wrote:
>
> - Original Message -
> > On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote:
> > > Hi,
> > >
> > > This series reworks some of our configure options to make Gallium
> > > easier to configure.
> > >
> > > First, there is a new
https://bugs.freedesktop.org/show_bug.cgi?id=37274
--- Comment #5 from okias 2011-06-14 10:41:48 PDT ---
~ $ GALLIUM_DUMP_CPU=1 glxgears
util_cpu_caps.nr_cpus = 2
util_cpu_caps.x86_cpu_type = 8
util_cpu_caps.cacheline = 64
util_cpu_caps.has_tsc = 1
util_cpu_caps.has_mmx = 1
util_cpu_caps.has_mmx2
- Original Message -
> On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote:
> > Hi,
> >
> > This series reworks some of our configure options to make Gallium
> > easier to configure.
> >
> > First, there is a new option --with-gallium-drivers=DIRS, which
> > replaces the current heap o
On Tue, Jun 14, 2011 at 12:25 PM, Marek Olšák wrote:
> Hi,
>
> This series reworks some of our configure options to make Gallium easier to
> configure.
>
> First, there is a new option --with-gallium-drivers=DIRS, which replaces the
> current heap of options --enable-gallium-DRIVER. --disable-ga
---
configure.ac |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 804b8a7..b2a0f66 100644
--- a/configure.ac
+++ b/configure.ac
@@ -550,13 +550,13 @@ AC_ARG_ENABLE([egl],
[enable_egl=yes])
# Option for Gallium drivers
-GALLIUM_DR
On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote:
> Hi,
>
> This series reworks some of our configure options to make Gallium easier to
> configure.
>
> First, there is a new option --with-gallium-drivers=DIRS, which replaces the
> current heap of options --enable-gallium-DRIVER. --disable-
We already have --enable-gallium, --enable-egl, and --with-state-trackers=egl.
---
configure.ac | 30 --
1 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/configure.ac b/configure.ac
index 69513c1..90171fa 100644
--- a/configure.ac
+++ b/configure.ac
@@
There is an obvious redundancy:
--with-driver=dri VS --with-state-trackers=dri
--with-driver=xlib VS --with-state-trackers=glx
--enable-openvg VS --with-state-trackers=vega
--enable-egl VS --with-state-trackers=egl
This patch adds two new options for the remaining state trackers:
--enable-xorg
--
---
src/gallium/SConscript| 11 +
src/gallium/drivers/r600/SConscript | 37 -
src/gallium/targets/dri-r600/SConscript | 25 ---
src/gallium/targets/egl-static/SConscript |7 -
src/gallium/winsys/SConscrip
It's not like anybody needs to build that on Windows.
---
Makefile |1 -
src/gallium/SConscript|3 -
src/gallium/drivers/r300/SConscript | 44 -
src/gallium/targets/dri-r300/SConscript | 26
This removes all the --enable-gallium-$driver options and --disable-gallium.
Gallium can be disabled by --with-gallium-drivers= (without parameters).
Default is:
--with-gallium-drivers=r300,swrast
---
configure.ac | 165 --
1 files changed
Hi,
This series reworks some of our configure options to make Gallium easier to
configure.
First, there is a new option --with-gallium-drivers=DIRS, which replaces the
current heap of options --enable-gallium-DRIVER. --disable-gallium is removed
as well, instead, --with-gallium-drivers= withou
On Tue, 2011-06-14 at 09:39 -0600, Brian Paul wrote:
> Good question. I was thinking that the interleaved vs.
> non-interleaved paths could probably be merged with a little work. I
> don't remember the original reason for doing things as they are.
I think it enabled an easier upload path withi
https://bugs.freedesktop.org/show_bug.cgi?id=38301
jukari...@gmail.com changed:
What|Removed |Added
Component|Drivers/DRI/nouveau |Mesa core
AssignedTo|nouvea
Good question. I was thinking that the interleaved vs.
non-interleaved paths could probably be merged with a little work. I
don't remember the original reason for doing things as they are.
-Brian
On 06/14/2011 08:55 AM, Jose Fonseca wrote:
Looks good Brian.
BTW, does detecting interleav
Looks good Brian.
BTW, does detecting interleaved arrays still provide any advantage for current
HW drivers?
Jose
- Original Message -
> Check that the difference in array pointers/offsets from the 0th
> array are less than the stride, for both VBOs and user-space arrays.
> Previously,
On Tue, 14 Jun 2011 15:21:13 +0200, Lampersperger Andreas
wrote:
> Which Versions of
>
> libdrm
> mesa
> xf86_video_intel
> xorg-server
> gtkglext
> linux-kernel
>
> do you use?
All apart from gtkglext were compiled from git with my own patches
included. None of those patches were to addres
Which Versions of
libdrm
mesa
xf86_video_intel
xorg-server
gtkglext
linux-kernel
do you use?
You think the most suspect part is i915.ko? I watched (via systemtap) all calls
to drm_gem_object_alloc(), drm_gem_object_free(), and to
drm_gem_object_destroy() (in drm.ko) and I saw that with ever
On Tue, 14 Jun 2011 13:05:56 +0200, Lampersperger Andreas
wrote:
> Hello Chris,
>
> I have modified the simple.c from the gtkglext examples. Just replace in
> gtkglext-1.2.0/examples the original simple.c with the attached version.
Builds fine. I see a flashing quadric (every other frame, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can you please confirm the tarballs. gzip and bzip2 tarballs won't
extract here throwing errors until you give tar -f parameter. I can't
build packages because our packaging system uses simple bsdtar without
further options.
tar -tvf ~/arch64/sources/
Hello Chris,
I have modified the simple.c from the gtkglext examples. Just replace in
gtkglext-1.2.0/examples the original simple.c with the attached version.
-Andreas
-Ursprüngliche Nachricht-
Von: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Gesendet: Dienstag, 14. Juni 2011 12:50
On Tue, 14 Jun 2011 12:20:28 +0200, Lampersperger Andreas
wrote:
> Hello,
>
> running my application over a long time results in a kernel freeze or OOM
> kill, because reparenting a gtkglext drawing area on a intel i965 causes a
> leak of gem_objects.
That sounds like a simple test case to co
Hello,
running my application over a long time results in a kernel freeze or OOM kill,
because reparenting a gtkglext drawing area on a intel i965 causes a leak of
gem_objects. I use the following versions:
kernel 2.6.33.9
libdrm 2.4.23
xorg-server 1.10.2
xf86-video-intel-2.15
gtkglext-1.2.0
me
On Monday, June 13, 2011 17:55:35 Alex Deucher wrote:
> These first 4 look good to me. I've done a piglit run with them and
> no regressions. I've gone ahead and applied them.
Thanks!
Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
ht
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/2011 01:42 PM, Eric Anholt wrote:
> The path taken is wildly different based on this (do we generate from
> a temporary image, or from level-1's data), and we appear to have
> stride bugs in the compressed case that are tough to disentangle.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/2011 03:44 PM, Eric Anholt wrote:
> On Fri, 10 Jun 2011 15:17:12 -0600, Brian Paul wrote:
>> On 06/10/2011 02:38 PM, Eric Anholt wrote:
>>> We were using the default 4x2 alignment instead of the 4x4 required
>>> for non-FXT compressed texture
53 matches
Mail list logo
