cd ../Mesa-7.0.4/
git pull origin i915tex_branch
git pull origin mesa_7_0_branch
git log
commit 45eb62ad6159408807ff86d24dd972e0f39cefb8
Merge: 97eb335... 7734956...
Author: root [EMAIL PROTECTED]
Date: Mon Jul 21 09:50:15 2008 +0100
Merge branch 'i915tex_branch' of
http://bugs.freedesktop.org/show_bug.cgi?id=16786
Summary: mesa-7.1: googleearth, sauerbraten not working anymore
Product: Mesa
Version: 7.1
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority:
drm_lock_take(); and drm_lock_free(); are called from
drm_locked_tasklet_func(); which disables interrupts when grabbing its
spinlock.
Don't allow these locking functions to re-enable interrupts when
the tasklet expects them disabled. I.e. use spin_lock_irqsave instead of
spin_lock_bh (with their
Hi folks,
since my compiler always complains about that during (aborted)
compilation of the kernel modules I decided to send that patch to the ML.
Can we safely replace TRUE/FALSE by the boolean values true/false?
Cheers, Johannes
Signed-off-by: Johannes Engel [EMAIL PROTECTED]
Replace old
http://bugs.freedesktop.org/show_bug.cgi?id=16786
Roland Scheidegger [EMAIL PROTECTED] changed:
What|Removed |Added
Component|Drivers/DRI/Radeon |Drivers/DRI/r300
On 20.07.2008 19:32, Corbin Simpson wrote:
Howdy. I was just going through the r3xx/r5xx bugs, and I noticed that
lots of problems are related to certain texture compression features
being dependent on out-of-tree code. I also noticed that, at least on
R400+ Radeons, we actually have hardware
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger wrote:
On 20.07.2008 19:32, Corbin Simpson wrote:
Howdy. I was just going through the r3xx/r5xx bugs, and I noticed that
lots of problems are related to certain texture compression features
being dependent on out-of-tree code. I
On Sunday, July 20, 2008 3:10 am Maarten Maathuis wrote:
Has it been considered to put this up somewhere for autogeneration?
I'm not very familiar with these documentation schemes, but i imagine
it's a matter of putting appropriately styled comments in code and
they'll appear?
It would be a
On Sunday, July 20, 2008 3:46 am Michel Dänzer wrote:
On Sat, 2008-07-19 at 12:54 -0400, Robert Noland wrote:
One other issue that I spotted while testing is that we initialize
vblank_disable_allowed to 0. The only place that it ever becomes true
is in post modeset. So, for me... vblanks
So ALL Radeons can do decompression. Right now we have a system where
we
only upload S3TC textures if they were precompressed (NWN, UT2K4, etc.)
and we have to force the extension on in order to do it.
This may be slightly off topic, but I am wondering if there's any way to
detect the ability
http://bugzilla.kernel.org/show_bug.cgi?id=10985
--- Comment #35 from [EMAIL PROTECTED] 2008-07-21 13:01 ---
Created an attachment (id=16927)
-- (http://bugzilla.kernel.org/attachment.cgi?id=16927action=view)
disable panel restore all panel state first
this one tries to disable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced
it). Wine and
http://bugzilla.kernel.org/show_bug.cgi?id=10985
--- Comment #36 from [EMAIL PROTECTED] 2008-07-21 13:59 ---
Hello; tried that patch against refs/heads/master = b5cddbcc1536 ; I'm afraid
it did not fix it.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp Klaus Krause wrote:
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user
On 21.07.2008 22:09, Philipp Klaus Krause wrote:
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced
it). Wine and
On 21.07.2008 23:10, Corbin Simpson wrote:
Philipp Klaus Krause wrote:
Stefan Dösinger schrieb:
This may be slightly off topic, but I am wondering if there's any way to
detect the ability to upload precompressed textures when
GL_EXT_texture_compression_s3tc is not available(aka the user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Scheidegger schrieb:
If you only use DXT1 there's EXT_texture_compression_dxt1. It offers
support for using DXT1 precompressed textures. However AFAIK it'S
currently not supported in the free drivers (even if
GL_EXT_texture_compression_s3tc
http://bugzilla.kernel.org/show_bug.cgi?id=10985
--- Comment #37 from [EMAIL PROTECTED] 2008-07-21 14:41 ---
And I don't suppose the register diff changes either?
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Dösinger wrote:
| So ALL Radeons can do decompression. Right now we have a system where
| we
| only upload S3TC textures if they were precompressed (NWN, UT2K4, etc.)
| and we have to force the extension on in order to do it.
| This may be
19 matches
Mail list logo
