On Tue, Feb 26, 2013 at 11:15 PM, Eric Anholt wrote:
> I want to reuse intel_miptree_map() to replace some region mapping that's
> broken for separate stencil, but doing so would result in new demands on
> ETC transcode that we actually don't want to happen.
> ---
> src/mesa/drivers/dri/intel/int
---
Depends on Brian's remove-mfeatures branch.
configure.ac |3 ---
src/gallium/targets/egl-static/Makefile.am |3 +--
src/glsl/Makefile.am |3 +--
src/mesa/Makefile.am |2 +-
src/mesa/drivers/dri/common/Ma
- Original Message -
> Jordan Justen writes:
>
> > Motivated by wanting to see if GenTextures was called by an
> > application while debugging another Steam overlay issue.
>
> Making a systematic MESA_DEBUG=api using dispatch tables and code
> generation seems like it would be nice inste
What is this good for? Is it for UAVs? (unordered access views)
For UAVs, I think there is ARB_shader_storage_buffer_object and
pipe_context::set_shader_resources.
Marek
On Wed, Feb 27, 2013 at 3:18 AM, wrote:
> From: Roland Scheidegger
>
> Unfortunately not usable from OpenGL, and no cap bit
- Original Message -
> What is this good for? Is it for UAVs? (unordered access views)
No, it is just a standard D3D10 feature:
http://msdn.microsoft.com/en-gb/library/windows/desktop/bb204897.aspx
Not sure if there's a particular use case for it (e.g, maybe DirectCompute uses
this exte
https://bugs.freedesktop.org/show_bug.cgi?id=61361
--- Comment #1 from Andreas Boll ---
Does this happen if you build from git or from release tarball?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=57018
--- Comment #2 from Andreas Boll ---
Does this happen if you build from git or from release tarball?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
On 27.02.2013 10:44, Jose Fonseca wrote:
> - Original Message -
>> What is this good for? Is it for UAVs? (unordered access views)
> No, it is just a standard D3D10 feature:
> http://msdn.microsoft.com/en-gb/library/windows/desktop/bb204897.aspx
>
> Not sure if there's a particular use cas
https://bugs.freedesktop.org/show_bug.cgi?id=61415
Francisco Jerez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=61415
--- Comment #7 from Mike Lothian ---
Please could you clarify what libraries should be installed into this
directory?
I was building i965 r600g and clover all together and wasn't seeing anything in
there
--
You are receiving this mail because
This patch breaks the build with following config:
./autogen.sh \
--enable-xlib-glx \
--disable-driglx-direct \
--disable-dri \
--enable-debug \
--enable-gles1 \
--enable-gles2 \
--enable-openvg \
--enable-gallium-egl \
--enable-xa \
--enable-xorg
The probl
https://bugs.freedesktop.org/show_bug.cgi?id=61412
--- Comment #22 from Roland Scheidegger ---
I think if you had fog active by accident that would contribute to the feeling
there's probably no real use case for glBitmap with active fog hence probably
noone really interested in making that fast (
https://bugs.freedesktop.org/show_bug.cgi?id=61415
--- Comment #8 from Francisco Jerez ---
(In reply to comment #7)
> Please could you clarify what libraries should be installed into this
> directory?
>
> I was building i965 r600g and clover all together and wasn't seeing anything
> in there
Y
Am 27.02.2013 12:05, schrieb Christoph Bumiller:
> On 27.02.2013 10:44, Jose Fonseca wrote:
>> - Original Message -
>>> What is this good for? Is it for UAVs? (unordered access views)
>> No, it is just a standard D3D10 feature:
>> http://msdn.microsoft.com/en-gb/library/windows/desktop/bb2
Looks good.
I think the u_surface change could go in separately though.
BTW, now that we can render/sampler from buffers,
llvmpipe_is_resource_referenced needs to be updated: buffer may be referenced
if they have BIND_SAMPLER/RENDERTARGET.
Weshould do something like if !BIND_SAMPLER/RENDERTARG
Am 27.02.2013 14:11, schrieb Jose Fonseca:
> Looks good.
>
> I think the u_surface change could go in separately though.
Ok.
>
> BTW, now that we can render/sampler from buffers,
> llvmpipe_is_resource_referenced needs to be updated: buffer may be referenced
> if they have BIND_SAMPLER/RENDERT
https://bugs.freedesktop.org/show_bug.cgi?id=61364
a.ra...@arcor.de changed:
What|Removed |Added
CC||a.ra...@arcor.de
--
You are receiving
On 04/05/2011 22:50, Adam Jackson wrote:
> ... and clean up if it didn't.
>
> Signed-off-by: Adam Jackson
> ---
> src/glx/glx_pbuffer.c | 76
> -
> src/glx/glxcmds.c | 74 +++-
> 2 files changed,
Now that the make target is supported, I've turned on 'make check' for mesa in
my tinderbox, but it fails [1]
The logic behind patch [3/3] is sufficently convoluted that I'm not sure I've
got it right. However, I'm pretty sure that the code is wrong as it stands, as
it's checking for a #define
Signed-off-by: Jon TURNEY
---
src/mapi/glapi/tests/Makefile.am |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mapi/glapi/tests/Makefile.am b/src/mapi/glapi/tests/Makefile.am
index a23eef2..3553b99 100644
--- a/src/mapi/glapi/tests/Makefile.am
+++ b/src/mapi/glap
It looks like this has been broken since commit
1a1db1746db82efc7f0643508886dfc78a15eb71 "Standardize names of OpenGL
functions."
Signed-off-by: Jon TURNEY
---
src/mapi/glapi/tests/check_table.cpp | 528 +-
1 files changed, 264 insertions(+), 264 deletions(-)
di
Actually use $DEFINES, so we can see if GLX_INDIRECT_RENDERING is defined
If GLX_INDIRECT_RENDERING is defined, _GLAPI_SKIP_PROTO_ENTRY_POINTS will
be defined, and libglapi won't contain the 'protocol entry points', so we
should provide stubs in check_table.cpp
Signed-off-by: Jon TURNEY
---
sr
On Wed, Feb 27, 2013 at 1:21 AM, Jose Fonseca wrote:
> - Original Message -
>> Jordan Justen writes:
>>
>> > Motivated by wanting to see if GenTextures was called by an
>> > application while debugging another Steam overlay issue.
>>
>> Making a systematic MESA_DEBUG=api using dispatch ta
Jose Fonseca writes:
> - Original Message -
>> Jordan Justen writes:
>>
>> > Motivated by wanting to see if GenTextures was called by an
>> > application while debugging another Steam overlay issue.
>>
>> Making a systematic MESA_DEBUG=api using dispatch tables and code
>> generation s
- Original Message -
> On Wed, Feb 27, 2013 at 1:21 AM, Jose Fonseca wrote:
> > - Original Message -
> >> Jordan Justen writes:
> >>
> >> > Motivated by wanting to see if GenTextures was called by an
> >> > application while debugging another Steam overlay issue.
> >>
> >> Making
On Wed, 2013-02-27 at 14:02 +, Jon TURNEY wrote:
> Attached is a patch to fix.
Pushed, thanks.
- ajax
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Roland Scheidegger
Now that buffers can be used as textures or render targets
make sure they aren't skipped.
Fix suggested by Jose Fonseca.
---
src/gallium/drivers/llvmpipe/lp_surface.c | 14 +++---
src/gallium/drivers/llvmpipe/lp_texture.c |4 +++-
2 files changed, 10 inser
On 02/26/2013 11:15 PM, Eric Anholt wrote:
> I have some debug of HiZ rendering that looks like some rendering is not
> landing in my HiZ buffer. Unfortunately, fulsim choking on us violating
> hiz rendering rules was preventing me from using it as a debug aid.
>
> Once we get things reliable, we
On 02/26/2013 11:15 PM, Eric Anholt wrote:
> ---
> src/mesa/drivers/dri/i965/gen6_blorp.cpp |3 +++
> src/mesa/drivers/dri/i965/gen7_blorp.cpp |3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
On 02/26/2013 11:15 PM, Eric Anholt wrote:
> Now that we have W-tiled S8, we can't just region_map and poke at bits --
> there has to be some swizzling. Rely on intel_miptree_map to get that job
> done. This should also get the highest performance path we know of for the
> mapping (interesting if
Chad Versace writes:
> On 02/26/2013 11:15 PM, Eric Anholt wrote:
>> I have some debug of HiZ rendering that looks like some rendering is not
>> landing in my HiZ buffer. Unfortunately, fulsim choking on us violating
>> hiz rendering rules was preventing me from using it as a debug aid.
>>
>> O
Catched this that morning
>From e50374e62254e7532c695bebb3e608242638bb73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?=
Date: Wed, 27 Feb 2013 10:24:10 +0100
Subject: [PATCH] tgsi: fix mis-matching instruction emission
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_aos.c |
https://bugs.freedesktop.org/show_bug.cgi?id=61364
marci...@gmail.com changed:
What|Removed |Added
CC||marci...@gmail.com
--
You are recei
Good catch. Thanks!
Jose
- Original Message -
> Catched this that morning
>
>
> From e50374e62254e7532c695bebb3e608242638bb73 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Maxence=20Le=20Dor=C3=A9?= < maxence.led...@gmail.com >
> Date: Wed, 27 Feb 2013 10:24:10 +0100
> Subject: [PATCH] tgs
On 02/27/2013 11:39 AM, Eric Anholt wrote:
> Chad Versace writes:
>
>> On 02/26/2013 11:15 PM, Eric Anholt wrote:
>>> I have some debug of HiZ rendering that looks like some rendering is not
>>> landing in my HiZ buffer. Unfortunately, fulsim choking on us violating
>>> hiz rendering rules was p
https://bugs.freedesktop.org/show_bug.cgi?id=46376
--- Comment #5 from Kenneth Graunke ---
I don't understand how to reproduce this bug. What do you mean by "only X"?
GNOME uses X. I've also verified that they work fine in KDE (also using X).
Can you provide some instructions on how to reprod
From: Brian Paul
No longer pass -a flag to get_hash_generate.py script to specify
OpenGL, ES1, ES2, etc.
v2[chadv]: Fix Android makefile too.
---
Brian, this patch in your series breaks the Android build. Here is
a fixed version of your patch. The only difference is the hunk in
file Android.gen
The field was equivalent to (etc_format != MESA_FORMAT_NONE), and
therefore duplicate information.
This patch removes field and replaces all references to it with
`etc_format != MESA_FORMAT_NONE`.
No Piglit ETC test regresses on Intel Sandybridge.
Signed-off-by: Chad Versace
---
src/mesa/drive
> >> Could you please test glxgears and other simple mesa demos? It's easier
> >> to spot the problems with small apps that don't use a lot of complex
> >> shaders. If some of them don't work correctly, please send me the dumps
> >> with "R600_DUMP_SHADERS=2 R600_SB_DUMP=3".
> >
> > All of the mesa
Yeah the tgsi_aos emit code doesn't really get much testing, as it isn't
actually used anywhere. It might have other unnoticed bugs.
Roland
Am 27.02.2013 21:21, schrieb Jose Fonseca:
> Good catch. Thanks!
>
> Jose
>
> - Original Message -
>> Catched this that morning
>>
>>
>> From e5037
On 02/27/2013 01:31 PM, Chad Versace wrote:
The field was equivalent to (etc_format != MESA_FORMAT_NONE), and
therefore duplicate information.
This patch removes field and replaces all references to it with
`etc_format != MESA_FORMAT_NONE`.
No Piglit ETC test regresses on Intel Sandybridge.
Si
The states were split because we thought it caused a hardlock. Now we know
the hardlock was caused by something else and has since been fixed.
---
src/gallium/drivers/r600/evergreen_state.c |3 +--
src/gallium/drivers/r600/r600_hw_context.c |1 -
src/gallium/drivers/r600/r600_pipe.h
These registers are either already emitted elsewhere or moved to start_cs.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 42 ---
src/gallium/drivers/r600/evergreen_state.c | 14
src/gallium/drivers/r600/r600_hw_context.c |3 --
3 files changed
NOTE: This is a candidate for the 9.1 branch.
---
src/gallium/drivers/r600/r600_pipe.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index e2d86e9..27c98ec 100644
--- a/src/galliu
---
src/gallium/auxiliary/util/u_range.h | 91 ++
1 file changed, 91 insertions(+)
create mode 100644 src/gallium/auxiliary/util/u_range.h
diff --git a/src/gallium/auxiliary/util/u_range.h
b/src/gallium/auxiliary/util/u_range.h
new file mode 100644
index 00
Any driver can implement this simple and efficient optimization.
Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
with TF2 anymore, so we avoid a ton of useless buffer copies.
---
src/gallium/drivers/r600/evergreen_hw_context.c |3 +++
src/gallium/drivers/r600/evergr
On Wed, Feb 27, 2013 at 1:31 PM, Chad Versace
wrote:
> The field was equivalent to (etc_format != MESA_FORMAT_NONE), and
> therefore duplicate information.
>
> This patch removes field and replaces all references to it with
> `etc_format != MESA_FORMAT_NONE`.
>
> No Piglit ETC test regresses on In
https://bugs.freedesktop.org/show_bug.cgi?id=61361
--- Comment #2 from Dennis Heuer ---
release tarball
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fre
On Wed, Feb 27, 2013 at 2:32 AM, Pohjolainen, Topi
wrote:
> On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote:
>> On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen
>> wrote:
>> > Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader
>> > program with instructions that
On Wed, Feb 27, 2013 at 6:11 PM, Marek Olšák wrote:
> Any driver can implement this simple and efficient optimization.
> Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
> with TF2 anymore, so we avoid a ton of useless buffer copies.
With this patch applied are you stil
On 02/27/2013 04:11 PM, Marek Olšák wrote:
---
src/gallium/auxiliary/util/u_range.h | 91 ++
1 file changed, 91 insertions(+)
create mode 100644 src/gallium/auxiliary/util/u_range.h
diff --git a/src/gallium/auxiliary/util/u_range.h
b/src/gallium/auxiliary/
On 02/27/2013 02:17 PM, Chad Versace wrote:
From: Brian Paul
No longer pass -a flag to get_hash_generate.py script to specify
OpenGL, ES1, ES2, etc.
v2[chadv]: Fix Android makefile too.
---
Brian, this patch in your series breaks the Android build. Here is
a fixed version of your patch. The on
On 02/26/2013 10:16 AM, Andreas Boll wrote:
2013/2/26 Brian Paul:
OK, I have a git tree on fd.o with this patch series (plus updates to
intel_screen.c and configure.ac).
With your configure.ac patch API_DEFINES seems now unused.
But from what I can see src/gallium/targets/egl-static/egl_st.c u
https://bugs.freedesktop.org/show_bug.cgi?id=61582
Priority: medium
Bug ID: 61582
Assignee: mesa-dev@lists.freedesktop.org
Summary: meta ops should log perf debug messages when they fall
back to software
Severity: enhancement
https://bugs.freedesktop.org/show_bug.cgi?id=61412
Ian Romanick changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
From: Paul Berry
This bug is currently benign, since get_called_parameter_string() is
currently only used for functions that return true for
glx_function.has_different_protocol(), and none of those functions
include padding. However, in order to implement marshalling of GL API
functions, we'll n
From: Paul Berry
Without this patch, $$.negate, $$.rgba_valid, and $$.xyzw_valid take
on garbage values. At the moment this problem is benign (the garbage
values happen to be zero), but in my experiments executing GL
operations on a background thread, the garbage values change, leading
to piglit
Here's a small series of fixes that have accumulated in the glthread-5
branch, located in my tree as "glthread-push". Patch 1 replaces the "LOL
HAX" commit of glthread-5, which I'll be rebasing out as my next step
there.
The glapi attribute additions aren't strictly fixes, but I think it's good t
Since stdbool.h's "true" and "false" are #defines, they got expanded when
used as macro arguments, and that expanded value was stored in the
XML string, producing XML that driconf would then fail to parse.
Currently no drivers included stdbool along with driconf, but I keep
accidentally doing so o
This is the kind of information that would have been present for GLX, if
GLX supported modern GL. This allows these entrypoints to get automatic
asynchronous marshalling code generated for glthread.
---
src/mapi/glapi/gen/GL3x.xml | 16 +-
src/mapi/glapi/gen/gl_API.xml | 68
This causes this function to become asynchronous with glthread.
---
src/mapi/glapi/gen/gl_API.xml |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 803b1aa..aa3e8a8 100644
--- a/src/mapi/glapi/gen/gl_API.x
On 02/27/2013 03:41 PM, Kristian Høgsberg wrote:
On Wed, Feb 27, 2013 at 2:32 AM, Pohjolainen, Topi
wrote:
On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote:
On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen
wrote:
Namely YUV420, YVU420 (YV12) and NV12. Here one extends the s
https://bugs.freedesktop.org/show_bug.cgi?id=46376
--- Comment #6 from libo ---
Sorry for my ambiguous explanation.
"only X" mean that only execute command "xinit" but not start gnome or KDE
before run the demo.
for example:
1.xinit&
2../gloss
To the contrary, for example,
1.xinit&
2.gnome
2../g
This little patch series adds support for creating a __DRIimage from a
prime/dma_buf fd and then uses that to add support for wl_drm buffer sharing
by fd-passing. The __DRIimage patch is interesting in itself as it
should enable the EGL_EXT_dmabuf_image extension that's come up
a few times.
Krist
No functional change here, but this will let us query the image
for an fd handle later.
---
src/egl/drivers/dri2/egl_dri2.h | 3 +-
src/egl/drivers/dri2/platform_wayland.c | 57 -
2 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/src/egl/driv
---
include/GL/internal/dri_interface.h| 14 +++-
src/mesa/drivers/dri/intel/intel_regions.c | 33 +++
src/mesa/drivers/dri/intel/intel_regions.h | 6
src/mesa/drivers/dri/intel/intel_screen.c | 53 --
4 files changed, 102 insertions(+
---
src/egl/drivers/dri2/egl_dri2.c | 27 ---
src/egl/drivers/dri2/egl_dri2.h | 1 +
src/egl/drivers/dri2/platform_wayland.c | 69 ++---
src/egl/wayland/wayland-drm/wayland-drm.c | 40 ++---
src/egl/wayland/wayland-drm/wayl
On Wed, Feb 27, 2013 at 8:15 PM, Ian Romanick wrote:
> On 02/27/2013 03:41 PM, Kristian Høgsberg wrote:
>>
>> On Wed, Feb 27, 2013 at 2:32 AM, Pohjolainen, Topi
>> wrote:
>>>
>>> On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote:
On Tue, Feb 26, 2013 at 8:19 AM, Topi Poh
On Mon, Feb 25, 2013 at 8:55 PM, Ian Romanick wrote:
> Also... are there piglit tests coming?
Not unless you convince me otherwise. I don't think I'll be able to
verify that said tests work however.
> More recent versions of the spec template include a section for describing
> conformance tests.
69 matches
Mail list logo
