On 03/05/2014 03:20 AM, Eric Anholt wrote:
We need the header setup to not be predicated on which pixels are
undiscarded. I'm not sure originally if I had thought that the mask
disable implied predicate disable, or if I had just misread the mask
disable as predicate disable. Either way, I know
Am 04.03.2014 22:12, schrieb Emil Velikov:
Currenly configure.ac will print a warning when one is missing the package.
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
configure.ac | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/confi
Am 04.03.2014 22:12, schrieb Emil Velikov:
All three (xvmc, vdpau and omx) do not have an alternative loading
similar to the dri modules. Thus one needs to explicitly install
them in order to use/test them.
It's not mainline yet, but at least I'm using
VDPAU_DRIVER_PATH=.../mesa/lib/gallium fo
On 03/04/2014 01:18 PM, Marek Olšák wrote:
> On Tue, Mar 4, 2014 at 8:05 AM, Ian Romanick wrote:
>> On 03/03/2014 03:25 AM, Marek Olšák wrote:
>>>
>>> From: Marek Olšák
>>>
>>> Softpipe expects a float in the vertex shader, which is what glEdgeFlag
>>> generates.
>>>
>>> This fixes piglit/g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mesa 10.1 has been released! Mesa 10.1 is a feature release that
includes many updates and enhancements. The full list is available in
the release notes file in docs/relnotes/10.1.html.
The tag in the GIT repository for Mesa 10.1 is 'mesa-10.1'.
Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=71547
--- Comment #5 from Matt Turner ---
Sigh. Patch sent.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fr
Because people insist on doing things like explicitly disabling SSE 4.1.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71547
---
src/mesa/main/streaming-load-memcpy.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/streaming-load-memcpy.c
b/src/mesa/main/streaming-l
https://bugs.freedesktop.org/show_bug.cgi?id=71547
--- Comment #4 from David "okias" Heidelberger ---
P.S. because SW is builded on one central machine, I have to use these flags
manually, so -march=native isn't solution.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=71547
David "okias" Heidelberger changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution
https://bugs.freedesktop.org/show_bug.cgi?id=71547
--- Comment #3 from David "okias" Heidelberger ---
This problem is valid,
gcc version 4.8.2
# gcc -march=native -E -v - &1 | grep cc1
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/cc1 -E -quiet -v - -march=k8-sse3
-mcx16 -msahf -mno-movbe -mno-ae
On Die, 2014-03-04 at 12:32 +0100, Marek Olšák wrote:
> From: Marek Olšák
>
> We don't have a piglit test for this, but I think it's correct.
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |
On Die, 2014-03-04 at 22:31 +0800, Chia-I Wu wrote:
> Hi,
>
> Until now, we do not support sRGB write for winsys framebuffers. This series
> changes that so that winsys framebuffers are marked sRGB-capable when the pipe
> driver supports it.
>
> This is not to be confused with GLX_FRAMEBUFFER_SR
On Wed, Mar 5, 2014 at 12:10 AM, Brian Paul wrote:
> Spotted by Chia-I Wu.
unpack_ubyte_ARGB_REV() needs the same care too. With that fixed,
this patch is
Reviewed-by: Chia-I Wu
> ---
> src/mesa/main/format_pack.c |2 +-
> src/mesa/main/format_unpack.c|8
> src/
On Mit, 2014-03-05 at 00:43 +0100, Marek Olšák wrote:
> I'm not an automake expect, but this might need to be done for gallivm
> too. It currently fails to compile with latest LLVM.
I was having trouble with that as well, because the output of
llvm-config didn't contain -std=c++11. I had to make c
On Mit, 2014-03-05 at 00:25 +0100, Marek Olšák wrote:
> I think this patch breaks geometry shaders with LLVM that doesn't
> support the kill instruction in GS. All GS piglit tests fail with:
>
> SILowerControlFlow.cpp:296: void
> {anonymous}::SILowerControlFlowPass::Kill(llvm::MachineInstr&):
> As
On 03/04/2014 05:20 PM, Eric Anholt wrote:
> We need the header setup to not be predicated on which pixels are
> undiscarded. I'm not sure originally if I had thought that the mask
> disable implied predicate disable, or if I had just misread the mask
> disable as predicate disable. Either way, I
---
If the core change lands, this could be squashed in with it as far as
I can see from the testcases we have.
src/mesa/drivers/dri/i965/brw_draw_upload.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_dra
We need the header setup to not be predicated on which pixels are
undiscarded. I'm not sure originally if I had thought that the mask
disable implied predicate disable, or if I had just misread the mask
disable as predicate disable. Either way, I know I had spent more time
thinking about this in
Add Intel driver hook for glGetTexImage to accelerate the case of reading
texture image into a PBO. This case gets huge performance gains by using
GPU BLIT directly to PBO rather than GPU BLIT to temporary texture followed
by memcpy.
No regressions on Piglit tests with Intel driver.
Performance
This patch introduces two pre-canned MOCS values: BDW_MOCS_WB
(write-back, all caches) and BDW_MOCS_WT (write-through, all caches).
We use write-through caching for render targets, and write-back for
all other data. (At least on Haswell, I believe write-back LLC/eLLC
didn't work for scan-out buff
On 02/28/2014 12:56 PM, Ian Romanick wrote:
On 02/28/2014 08:08 AM, Jon Ashburn wrote:
Add Intel driver hook for glGetTexImage to accelerate the case of
reading
texture image into a PBO. This case gets huge performance gains by
using
GPU BLIT directly to PBO rather than GPU BLIT to temporary
It's strange, I have just compiled with the latest llvm revision at
Arch's mesa-git repo (202852) without problems.
I'm not an automake expert either, but at gallium/auxiliary/Makefile.am
there's this:
AM_CXXFLAGS += \
$(GALLIUM_CFLAGS) \
$(LLVM_CXXFLAGS)
So I suppose, of course
https://bugs.freedesktop.org/show_bug.cgi?id=63717
Felix Schwarz changed:
What|Removed |Added
CC||felix.schwarz@oss.schwarz.e
https://bugs.freedesktop.org/show_bug.cgi?id=75779
turbolo...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=75779
--- Comment #4 from turbolo...@gmail.com ---
I think you can just go ahead and close this report, I mean if it simply is not
there then no problem. A table of supported stuff per target instead of Mesa
version would be very cool for those looking
https://bugs.freedesktop.org/show_bug.cgi?id=75779
--- Comment #3 from turbolo...@gmail.com ---
In the release notes of the newer versions it states that version OpenGL 3.1 is
supported but the version returned is 2.1 by glGetString. Then it goes on to
say that the 3.1 is available by creating a c
I'm not an automake expect, but this might need to be done for gallivm
too. It currently fails to compile with latest LLVM.
Marek
On Sun, Mar 2, 2014 at 10:39 PM, Bruno Jiménez wrote:
> ---
> src/gallium/state_trackers/clover/Makefile.am | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions
https://bugs.freedesktop.org/show_bug.cgi?id=75779
turbolo...@gmail.com changed:
What|Removed |Added
CC||turbolo...@gmail.com
--- Comment #
https://bugs.freedesktop.org/show_bug.cgi?id=75779
--- Comment #1 from Brian Paul ---
The windows gdi target/driver only supports OpenGL 2.1. Where do you see that
version 3.1 is supported on Windows in the docs?
In any case, glGenFrameBuffers() should work with an OpenGL 2.1 context. In
what
https://bugs.freedesktop.org/show_bug.cgi?id=75779
Priority: medium
Bug ID: 75779
Assignee: mesa-dev@lists.freedesktop.org
Summary: wglCreateContextAttribsARB is missing in software
rasterizer and does not work properly in gallium gdi
I think this patch breaks geometry shaders with LLVM that doesn't
support the kill instruction in GS. All GS piglit tests fail with:
SILowerControlFlow.cpp:296: void
{anonymous}::SILowerControlFlowPass::Kill(llvm::MachineInstr&):
Assertion `MBB.getParent()->getInfo()->ShaderType
== ShaderType::PIX
Fix a leaked vertex shader in u_blitter.c
Signed-off-by: Aaron Watry
CC: "10.1"
---
src/gallium/auxiliary/util/u_blitter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 95e7fb6..66b511e 100644
--- a/
On 03/04/2014 03:43 PM, Eric Anholt wrote:
/bin/sh defaults to dash on debian.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 258cb3d..3f75266 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1072,7 +1072,7 @@ if test -n "
/bin/sh defaults to dash on debian.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 258cb3d..3f75266 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1072,7 +1072,7 @@ if test -n "$with_dri_drivers"; then
dri_drivers=`IF
You check for streamout and CP DMA support, but you don't use
resource_copy_region if DMA is not supported. The CP DMA and
streamout-based buffer copying is only used by resource_copy_region.
The last parameter of buffer_wait should be RADEON_USAGE_WRITE (you're
waiting for the last write to the s
https://bugs.freedesktop.org/show_bug.cgi?id=75212
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
It was really only used in the radeon driver for a debug printf.
And evidently, libGL.so referenced it just to work around some sort
of linker issue.
This patch removes the two calls to the function and the function
itself.
Fixes undefined _glthread_GetID symbol in libGL reported by 'nm'.
Though,
There's already code for them due to the GenerateMipmap path, so we just
need to make sure we've got our coordinates present.
---
src/mesa/drivers/common/meta_blit.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/me
Similar to Anuj's change 0f6f92e284cb5.
---
src/mesa/main/teximage.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index a6c3581..4346c31 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -4487,8 +
Now that BindRenderbufferTexImage() is a thing that drivers can do, winsys
FBOs *can* have NeedsFinishRenderTexture set. The early exit here
predated the NFRT flag, so it did make sense at the time.
---
src/mesa/main/fbobject.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/mesa/main/f
The flag wasn't getting updated correctly when the ctx->DrawBuffer or
ctx->ReadBuffer changed. It usually ended up working out because most
apps only have one window system framebuffer, or if they have more than
one and they have any front read/drawing, they will have called
glReadBuffer()/glDrawB
Here's another series of meta stuff: Replacing the winsys MSAA blits with
meta instead of blorp where possible, and making CopyTexSubImage use meta
instead of blorp. In the process I found I had to fix some other bugs in
meta's BlitFramebuffer.
There are a few intel patches at the start to avoid
The few paths that were playing with framebuffers and renderbuffer were
saving and restoring them, but I was writing another path doing so in this
series, and forgot to.
---
src/mesa/drivers/common/meta.c | 36 +++-
src/mesa/drivers/common/meta.h | 2 ++
2 files ch
The meta patch supports all the same, except for the stencil case being
unaccelerated.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 105 ---
src/mesa/drivers/dri/i965/brw_context.h | 9 ---
src/mesa/drivers/dri/i965/intel_tex_copy.c | 9 +--
3 files changed
We have to be a little careful here, because BlitFB itself has a fallback
path that calls CopyTexSubImage(), so we reach over into its state to tell
it to skip that case.
---
src/mesa/drivers/common/meta.c | 177 ++--
src/mesa/drivers/common/meta.h | 1 +
---
src/mesa/drivers/common/meta.h | 8
src/mesa/drivers/common/meta_blit.c | 23 +++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 00553e2..5d60690 100644
--- a/src/mesa/driv
This gets us equivalent code paths on BDW and pre-BDW, except for stencil
(where we don't have MSAA stencil resolve code yet)
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 111 --
1 file changed, 103 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i96
This was being applied in a subset of the places that
intel_prepare_render() was called, to set the same flag that
intel_prepare_render() was setting.
---
src/mesa/drivers/dri/i965/brw_state_upload.c | 2 --
src/mesa/drivers/dri/i965/intel_buffers.c | 18 --
src/mesa/driver
It's the ctx->ReadBuffer that gets read from, not the ctx->DrawBuffer.
So, if you happened to have a ctx->ReadBuffer that was the winsys buffer,
and it had previously been intel_prepare_render()ed but not invalidated
since then, and you called glReadBuffer() to switch to front buffer
instead of bac
https://bugs.freedesktop.org/show_bug.cgi?id=75226
--- Comment #16 from Fredrik Höglund ---
(In reply to comment #15)
> Created attachment 95005 [details] [review]
> make winsys fbo sRGB-capable when supported
>
> This new patch is tested with llvmpipe and ilo, and is also sent to the list
>
>
On Tue, Mar 04, 2014 at 09:12:43PM +, Emil Velikov wrote:
> - As of commit cb080a10b68(configure.ac: Don't require shared LLVM when
> building OpenCL) opencl does not mandate using shared llvm.
> - Add a warning message that building with static llvm may cause
> compilation problems.
>
> XXX
In the cases where one links against the static glapi.la there
is no need to create temporary variables only to explicitly
link agaist it.
Instead use SHARED_GLAPI_LIB to explicitly indicate when one
is building and linking with the shared glapi provider.
Signed-off-by: Emil Velikov
---
src/gal
Static and shared builds were possible in the good old days
of static makefiles. Currently the build system does not
distinguish nor does anything special when one requests a
static build.
Print a warning message for the packager that static builds
are not supported and continue building shared li
- As of commit cb080a10b68(configure.ac: Don't require shared LLVM when
building OpenCL) opencl does not mandate using shared llvm.
- Add a warning message that building with static llvm may cause
compilation problems.
XXX: Tom please update the wiki [1]. Currently it lists the old configure
swi
The primary users of these are linux developers, although
it can be extended for *BSD and others if needed.
Fixes make install for Cygwin and OpenBSD at least.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63269
Cc: Jon TURNEY
Signed-off-by: Emil Velikov
---
configure.ac
From: Jon TURNEY
Recent commit fixed build issues in dri2_query_renderer.c by
wrapping in defined(direct_rendering) && !defined(applegl)
This patch targets the query_renderer tests, so that make check
passes on platforms such as hurd and cygwin.
v2: (Emil)
- Rebase and update commit message.
Some platforms different library extension - dll, dylib, a.
Honor that when we are creating the required links.
Rename LIB_EXTENSION to LIB_EXT while we're here.
XXX: With libglapi linking aside, building classic drivers
on non-linux platforms should be possible now.
Cc: Jon TURNEY
Signed-off-b
Prevent build issues on systems lacking libdrm.
Cc: Jon TURNEY
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/dri/Makefile.am | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/Makefile.am
b/src/gallium/state_trackers/dri/Makefil
Currenly configure.ac will print a warning when one is missing the package.
Signed-off-by: Emil Velikov
---
configure.ac | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 21db389..36d7895 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1
- xf86dri.h is the old dri1 header, not required by dri2 nor dri3
- fold xf86drm.h inclusiong inside dri2.h
- dri3_glx does not have any drm specific dependencies
- glapi.h is not required by the dri2 and dri3 codepaths
Signed-off-by: Emil Velikov
---
src/glx/dri2.c
All the variables were used before the automake conversion
and do not make sense (nor are used) currently.
Replace GL_LIB_NAME with lib$(GL_LIB).$(LIB_EXTENSION) for
apple-glx. The build has been broken for ages, but this will
ease the recovery process as it happens.
Signed-off-by: Emil Velikov
Drop the duplication accross all dri targets.
Signed-off-by: Emil Velikov
---
src/gallium/targets/dri-freedreno/Makefile.am | 7 +--
src/gallium/targets/dri-i915/Makefile.am | 6 +-
src/gallium/targets/dri-ilo/Makefile.am | 7 +--
src/gallium/targets/dri-nouveau/Makefile.a
This helper script will be used to minimise the duplication
during link generation across all gallium targets.
Signed-off-by: Emil Velikov
---
install-gallium-links.mk | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 install-gallium-links.mk
diff --git a/install
Signed-off-by: Emil Velikov
---
src/gallium/targets/egl-static/Makefile.am | 20 +---
src/gallium/targets/libgl-xlib/Makefile.am | 6 +-
src/gallium/targets/opencl/Makefile.am | 6 +-
src/gallium/targets/osmesa/Makefile.am | 9 +
4 files changed, 4 inser
From: Jon TURNEY
v2: (Emil)
- Do not link agaist libglapi.
Signed-off-by: Jon TURNEY
Signed-off-by: Emil Velikov
---
src/mesa/drivers/dri/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/Makefile.am b/src/mesa/drivers/dri/Makefile.am
index
All three (xvmc, vdpau and omx) do not have an alternative loading
similar to the dri modules. Thus one needs to explicitly install
them in order to use/test them.
Signed-off-by: Emil Velikov
---
src/gallium/targets/r600/omx/Makefile.am | 6 --
src/gallium/targets/r600/vdpau/Makefile.a
Use the handy script and minimise the boilerplate in the makefiles.
Signed-off-by: Emil Velikov
---
src/egl/wayland/wayland-egl/Makefile.am | 2 ++
src/mesa/drivers/osmesa/Makefile.am | 8 +---
src/mesa/drivers/x11/Makefile.am| 7 +--
3 files changed, 4 insertions(+), 13 dele
There is little gain in printing whenever a folder is created.
Signed-off-by: Emil Velikov
---
src/gallium/auxiliary/Makefile.am | 8
src/glsl/Makefile.am | 4 ++--
src/mesa/Makefile.am | 4 ++--
src/mesa/drivers/dri/Makefile.am | 2 +-
4 files changed, 9 inse
Use the automake predefined macro over hardcoding mkdir -p everywhere.
Signed-off-by: Emil Velikov
---
src/mapi/glapi/gen/glapi_gen.mk | 6 +++---
src/mesa/drivers/dri/common/xmlpool/Makefile.am | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mapi/glapi
Hi all,
An interesting cleanup series inspired by Jon Turney's tinderbox.
Highlights:
- Cleanup unused configure.ac variables dating from the static makefile days.
- Use platform specific library extension for links generation.
- Move all the link generation in three files.
- Make check fix w
There is little point in echoing everything that the script does
to stdout. Wrap it in AM_V_GEN so that a reasonable message is
printed as a indication of it's invocation.
Signed-off-by: Emil Velikov
---
install-lib-links.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ins
Signed-off-by: Emil Velikov
---
src/glsl/Makefile.am | 4 ++--
src/mesa/Makefile.am | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index 528f6f8..9f1507e 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
@@ -178,11 +
On Tue, Mar 4, 2014 at 1:08 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Volume 4, part 1 of the Ivybridge PRM says, "Generally, the EWA
> approximation algorithm results in higher image quality than the legacy
> algorithm." Using a classic anisotropic filtering "tunnel" demo, it
> appears t
On Tue, Mar 4, 2014 at 8:13 AM, Brian Paul wrote:
> Before, it was kind of ugly to set the multisample fields with
> assignments after we called _mesa_init_teximage_fields().
> ---
> src/mesa/main/teximage.c | 44 +---
> 1 file changed, 29 insertions(+),
https://bugs.freedesktop.org/show_bug.cgi?id=75751
--- Comment #4 from Kenneth Graunke ---
That's what --with-dri-drivers='' does. So presumably --disable-dri does
something else.
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Mar 4, 2014 at 2:14 AM, Ian Romanick wrote:
> On 03/02/2014 12:09 AM, Ilia Mirkin wrote:
>>
>> This adds enough code to let drivers implement texture clearing, but
>> doesn't actually do that for any of them.
>
>
> There's always the usual... this should be split into two patches. :)
> Gen
Looks good to me too!
Reviewed-by: Matthew McClure
Matthew
- Original Message -
From: "Roland Scheidegger"
To: "Zack Rusin" , mesa-dev@lists.freedesktop.org
Cc: jfons...@vmware.com, mcclu...@vmware.com
Sent: Tuesday, March 4, 2014 8:57:30 AM
Subject: Re: [PATCH] draw/llvm: fix generati
> Could you please do this without changing u_upload_mgr? You can still
> use u_upload_alloc to allocate buffer memory in the driver and the map
> buffer read/write flags are not important with persistent coherent
> buffer mappings anyway.
I have sent an updated patch to the list.
Ole
___
Using DMA for reads is much faster.
Signed-off-by: Niels Ole Salscheider
---
src/gallium/drivers/radeon/r600_buffer_common.c | 78 +++--
1 file changed, 60 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/rade
Am 04.03.2014 05:08, schrieb Zack Rusin:
> draw_current_shader_* functions return a final output when considering
> both the geometry shader and the vertex shader. But when code generating
> vertex shader we can not be using output slots from the geometry shader
> because, obviously, those can be c
On 03/04/2014 07:31 AM, Chia-I Wu wrote:
Hi,
Until now, we do not support sRGB write for winsys framebuffers. This series
changes that so that winsys framebuffers are marked sRGB-capable when the pipe
driver supports it.
This is not to be confused with GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB. The
at
Am 04.03.2014 17:10, schrieb Brian Paul:
> Spotted by Chia-I Wu.
> ---
> src/mesa/main/format_pack.c |2 +-
> src/mesa/main/format_unpack.c|8
> src/mesa/swrast/s_texfetch_tmp.h |8
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa
Before, it was kind of ugly to set the multisample fields with
assignments after we called _mesa_init_teximage_fields().
---
src/mesa/main/teximage.c | 44 +---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/
Spotted by Chia-I Wu.
---
src/mesa/main/format_pack.c |2 +-
src/mesa/main/format_unpack.c|8
src/mesa/swrast/s_texfetch_tmp.h |8
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index 2
On 03/03/2014 08:38 PM, Chia-I Wu wrote:
On Sat, Mar 1, 2014 at 1:59 AM, Brian Paul wrote:
Update the comments for the packed formats to accurately reflect the
layout of the bits in the pixel. For example, for the packed format
MESA_FORMAT_R8G8B8A8, R is in the least significant position while
https://bugs.freedesktop.org/show_bug.cgi?id=75543
--- Comment #4 from Brian Paul ---
Committed: cbacee207faf866b0444beb583d3d6f341a8ee78
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@list
On 03/04/2014 04:43 AM, Marek Olšák wrote:
From: Marek Olšák
Like L4A4.
---
src/gallium/auxiliary/util/u_format.csv | 4 ++--
src/gallium/auxiliary/util/u_format.h| 3 +--
src/gallium/drivers/ilo/ilo_format.c | 2 +-
src/gallium/include/pipe/p_format.h
I agree that apps that only write to a buffer shouldn't use both
MAP_UNSYNCHRONIZED and MAP_INVALIDATE_BUFFER_BIT, if that's your point. Apps
should stick so a single strategy. But it seems a common pitfall.
Note that MAP_INVALIDATE_*_BIT purpose is not just avoid synchronization. They
also a
https://bugs.freedesktop.org/show_bug.cgi?id=75751
--- Comment #3 from Christian Prochaska
---
> > In my understanding, if '--disable-dri' is given, libdrm should neither be a
> > requirement of the configure script nor should it get linked/used if it is
> > available.
>
> --disable-dri disables
In my opinion, MAP_UNSYNCHRONIZED says that you don't have to sync,
which makes MAP_INVALIDATE_* useless, because the invalidate flags are
only useful for avoiding synchronization and you already know you
don't have to do it.
Marek
On Thu, Feb 27, 2014 at 11:52 PM, Eric Anholt wrote:
> One thing
https://bugs.freedesktop.org/show_bug.cgi?id=75751
--- Comment #2 from Chia-I Wu ---
(In reply to comment #1)
> When I temporarily disabled the libdrm check, Mesa built fine with this
> configuration and the 'es2gears' demo ran without problems.
Right, libdrm should not be needed in your configur
- Original Message -
> - Original Message -
> > One thing I noticed while working on this was that we only reallocate
> > buffer
> > storage for INVALIDATE_BUFFER_BIT when UNSYNCHRONIZED_BIT is unset. The
> > ARB_mbr spec says that the contents "may be discarded", not "must be
>
- Original Message -
> One thing I noticed while working on this was that we only reallocate buffer
> storage for INVALIDATE_BUFFER_BIT when UNSYNCHRONIZED_BIT is unset. The
> ARB_mbr spec says that the contents "may be discarded", not "must be
> discarded". However, while writing the gla
This is about the compatibility profile, that is 3.0, and our piglit
tests which test these legacy formats. This isn't an issue with the
core profile for the reason you mentioned.
Marek
On Tue, Mar 4, 2014 at 3:31 PM, luigi wrote:
>
>>
>> From: Marek Ol??k
>>
>> There is no API for returning th
>
> From: Marek Ol??k
>
> There is no API for returning the number of luminance and intensity bits and
> the 3.3 spec doesn't seem to specify any behavior for the queries if the
> format
> is one of L, LA, I. It seems to be a spec bug.
>
>
hi.i just notice that:
GL 3.3 Core spec Chapter E.2.2
Hi,
Until now, we do not support sRGB write for winsys framebuffers. This series
changes that so that winsys framebuffers are marked sRGB-capable when the pipe
driver supports it.
This is not to be confused with GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB. The
attribute guarantees the created winsys frame
The texture formats of winsys fbo are always linear becase the st manager
(st/dri for example) could not know the colorspace used. But it does not mean
that we cannot make the fbo sRGB-capable. By
- setting rb->Visual.sRGBCapable to GL_TRUE when the pipe driver supports the
format in sRGB co
The format is mapped to PIPE_FORMAT_B8G8R8X8_SRGB.
---
src/mesa/state_tracker/st_format.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 5f951eb..25577ac 100644
--- a/src/mesa/state_trac
The format is needed to represent an RGB-only winsys framebuffer that is
sRGB-capable.
---
src/mesa/main/format_pack.c | 18 ++
src/mesa/main/format_unpack.c | 15 +++
src/mesa/main/formats.c | 21 +
src/mesa/main/formats.h | 3 +++
sr
On Tue, Mar 4, 2014 at 3:41 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> This can be called from locations that don't have a context pointer
> handy. This patch also adds enough infrastructure so that the unit
> tests for the GLSL compiler and the stand-alone compiler will build and
> functi
1 - 100 of 117 matches
Mail list logo
