Eric,
I think for gen6 most of the DP read in the pipeline should go through
constant cache instead of other caches. Maybe we should implement an
gen6_const_read_message.
That is better for performance.
Thanks
Zou Nanhai
>>-Original Message-
>>From: mesa-dev-bounces+nanha
Most of this is code movement to get the scratch space allocated in a
shared location. Other than that, the only real changes are that the
old oword block messages now operate on oword-aligned areas (with new
messages for unaligned access, which we don't do), and that the
caching control is in the
This was copy-and-paste from originally trying to get DP read/write
working reliably, and notably for other common messages (URB, sampler)
we weren't doing this.
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drive
Greetings,
As you can see, I pushed the core support for ARB_texture_float to master
after private discussion and acknowledgment. All Luca's work on this except
softpipe and llvmpipe patches has been merged to master, with me adding
missing pieces and fixing bugs.
The good news is Unigine Heaven
https://bugs.freedesktop.org/show_bug.cgi?id=36242
Summary: building with --enable-32-bit on a 64 bit machine
fails
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
Severity:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/13/2011 06:59 PM, Brian Paul wrote:
> On 04/13/2011 02:01 PM, Martin Olsson wrote:
>> Is there any version of mesa that provides software rendered opengl
>> 2.0 with
>> glsl 1.20 and either GL_ARB_framebuffer_object or one of the exts that
>> rep
On 04/14/2011 11:08 AM, jfons...@vmware.com wrote:
From: José Fonseca
We could actually try to do an early return both for gallium textures and
malloc memory textures, but I'm not sure exactly which situations
stImage->pt is NULL, and whether texImage->Data == NULL would be acceptible
or not.
--
From: José Fonseca
We could actually try to do an early return both for gallium textures and
malloc memory textures, but I'm not sure exactly which situations
stImage->pt is NULL, and whether texImage->Data == NULL would be acceptible
or not.
---
src/mesa/state_tracker/st_cb_texture.c |7 +++
https://bugs.freedesktop.org/show_bug.cgi?id=36182
--- Comment #17 from imamdxl8...@gmail.com 2011-04-14 09:59:16 PDT ---
Created an attachment (id=45618)
--> (https://bugs.freedesktop.org/attachment.cgi?id=45618)
terminal dump from game (debugging patch applied to Mesa)
System:
Ubuntu 10.10
Li
Updated patch as I was told that "an X component is supposed to result in 1.0".
On Thu, Apr 14, 2011 at 5:10 PM, Pierre-Eric Pelloux-Prayer
wrote:
> Another similar patch proposal : handling of
> PIPE_FORMAT_B8G8R8X8_UNORM format in st_fast_readpixels.
>
> If I'm correct the 'X' of B8G8R8X8 in st
https://bugs.freedesktop.org/show_bug.cgi?id=36238
Summary: Mesa release files don't contain scons control files
Product: Mesa
Version: 7.10
Platform: x86 (IA32)
OS/Version: Windows (All)
Status: NEW
Severity: normal
Hi,
Can you throw some hints here? Will certianly help.
thx
K
On Wed, Apr 13, 2011 at 7:49 AM, kumar vemuri wrote:
> OK. i tried your command i.e. "./configure --enable-debug
> --enable-gallium-swrast --with-driver=xlib"
> and did "make".
> I also ran "scons libgl-xlib" which i guess
Another similar patch proposal : handling of
PIPE_FORMAT_B8G8R8X8_UNORM format in st_fast_readpixels.
If I'm correct the 'X' of B8G8R8X8 in stands for 'whatever value' so I
think we could use the same code path for both
PIPE_FORMAT_B8G8R8A8_UNORM and PIPE_FORMAT_B8G8R8X8_UNORM.
(Blender uses glRe
https://bugs.freedesktop.org/show_bug.cgi?id=36182
--- Comment #16 from Marek Olšák 2011-04-14 07:57:31 PDT ---
(In reply to comment #15)
> just applied three patches to Mesa 7.10.2
>
> 28cec9e832b716b84c11ddabfcee74e0daf6ec49
> a9a02c8a39620515ec9fd0d774ce329cf67ecb4e manually to match Mesa 7.1
https://bugs.freedesktop.org/show_bug.cgi?id=36182
Frederic Romagne changed:
What|Removed |Added
CC||frederic.roma...@gmail.com
--
Config
On 04/13/2011 05:29 AM, Pierre-Eric wrote:
As Lightsmark seems to make use of glReadPixels with {GL_RGBA +
GL_UNSIGNED_INT_8_8_8_8} parameters,
I built a short patch to allow 'st_fast_readpixels' to handle this combination.
It's been tested using piglit's pixelFormat test + a custom app.
Best r
16 matches
Mail list logo