https://bugs.freedesktop.org/show_bug.cgi?id=59701
José Fonseca changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |jfons...@vmware.com
|or
On 01/28/2013 02:34 PM, Kenneth Graunke wrote:
The BLT engine has many limitations. Currently, it can only blit
X-tiled buffers (since we don't have a kernel API to whack the BLT
tiling mode register), which means all depth/stencil operations get
punted to meta code, which can be very CPU-intens
https://bugs.freedesktop.org/show_bug.cgi?id=44743
--- Comment #7 from José Fonseca ---
Does this still happen?
If so please provide /proc/cpuinfo, as it is possible that it is tied to your
particular processor settings.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=46528
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
- Original Message -
> On 01/28/2013 03:45 PM, srol...@vmware.com wrote:
> > From: Roland Scheidegger
> >
> > The struct padding got broken by
> > c789b981b244333cfc903bcd1e2fefc010500013.
> > This caused serious performance regression because part of the key
> > was
> > unitialized and hen
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 52 -
src/mesa/drivers/dri/i915/i915_vtbl.c | 58 ++--
src/mesa/drivers/dri/intel/intel_context.h |5 ++-
3 files changed, 58 insertions(+), 57 deletions(-)
diff --git a/src/mesa/drivers/
This is similar code to intel_miptree_copy_slice, but the knobs
are all set differently.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c | 18 ++---
src/mesa/drivers/dri/intel/intel_regions.c| 34 -
src/mesa/drivers/dri/intel/intel_regions.h| 13
I'm trying to move us away from the region structure, and all the
callers are currently dereferencing a miptree to get the region.
In this change, the map_refcount is dropped. However, the bo->virtual is
itself map refcounted, so that's already dealt with.
---
src/mesa/drivers/dri/intel/intel_mi
Mesa core is the place for encoding what format/type matches a mesa
format, so rely on that.
---
src/mesa/drivers/dri/intel/intel_tex_image.c | 28 +++---
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/d
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c
b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 1d02c2c..67b4c96 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/sr
The point of tracking the value was removed in February 2012
(65b096aeddd9b45ca038f44cc9adfff86c8c48b2), and this should have
been removed at the same time.
---
src/mesa/drivers/dri/intel/intel_context.h |8
src/mesa/drivers/dri/intel/intel_regions.c |6 --
2 files changed, 14
We were allowing things like copying RG1616 to a user's ARGB
format, while we were denying anything that wasn't ARGB or
RGB565.
---
src/mesa/drivers/dri/intel/intel_pixel.c | 32 -
src/mesa/drivers/dri/intel/intel_pixel.h |4
src/mesa/drivers/dr
I don't see any reason for it -- it was introduced with the DRI2
invalidate work by krh in 2010 with no explanation. I suspect it was
something about wanting the same drm_intel_bo struct underneath multiple
openings of the BO within one process, but that's covered by libdrm at
this point. As far
Part of my motivation here was the number of cache misses we have in the first
reference of a region after referencing the miptree wrapping it, for things
that should all live in the first cacheline of one struct.
I think I've made it as far into killing the region as I want to go before
Abdiel la
It's now always called from the same file.
---
src/mesa/drivers/dri/i915/i830_vtbl.c | 17 +++--
src/mesa/drivers/dri/i915/i915_vtbl.c | 17 +++--
src/mesa/drivers/dri/intel/intel_context.h |4
3 files changed, 14 insertions(+), 24 deletions(-)
diff
We don't need any of the other fields at that point.
---
src/mesa/drivers/dri/i915/i830_context.h | 10 -
src/mesa/drivers/dri/i915/i830_vtbl.c| 33 +
src/mesa/drivers/dri/i915/i915_context.h | 13
src/mesa/drivers/dri/i915/i915_vtbl.c
On 01/28/2013 04:02 PM, Christoph Bumiller wrote:
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
On 01/28/2013 05:06 PM, Frank Henigman wrote:
Set fs_visitor::params_remap to NULL in the constructor.
This variable was potentially tested in fs_visitor::remove_dead_constants()
before being set.
Signed-off-by: Frank Henigman
This patch is
Reviewed-by: Ian Romanick
Also, please add the fo
On 01/28/2013 05:06 PM, Frank Henigman wrote:
An assertion in fs_visitor::remove_dead_constants() would fail on
code like this, which accesses a non-existent uniform:
uniform vec u[1];
...
a += u[0] + u[1];
Shader code is checked for that error, but apparently only before
transformations
Eric Anholt writes:
> for tracking down the actual worst-case CPUwe'.
Looks like some typo there. "CPUs"?
Otherwise:
Reviewed-by: Carl Worth
-Carl
--
carl.d.wo...@intel.com
pgpmMzh1o7xZH.pgp
Description: PGP signature
___
mesa-dev mailing list
m
https://bugs.freedesktop.org/show_bug.cgi?id=59331
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Ian Romanick
Set fs_visitor::params_remap to NULL in the constructor.
This variable was potentially tested in fs_visitor::remove_dead_constants()
before being set.
Signed-off-by: Frank Henigman
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/dri
An assertion in fs_visitor::remove_dead_constants() would fail on
code like this, which accesses a non-existent uniform:
uniform vec u[1];
...
a += u[0] + u[1];
Shader code is checked for that error, but apparently only before
transformations like loop unrolling. So the following code would
While most of our development and testing is on x86-64, some of our
major consumers of the driver are on i386 still. On i386, the compiler
defaults to maximum compatibility, so we aren't taking advantage of cmov
instructions or SSE for floating point math, unless the user went out of
their way to
https://bugs.freedesktop.org/show_bug.cgi?id=59833
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|mesa-dev@list
Kenneth Graunke writes:
> Previously, BLORP only handled BlitFramebuffer. This patch adds an
> additional frontend for doing CopyTexSubImage. It also makes it the
> default.
Reading through the patch, it looks like there are two independent
things happening here---extending blorp to support a c
https://bugs.freedesktop.org/show_bug.cgi?id=59688
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|mesa-dev@list
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
v
On 01/28/2013 03:45 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
The struct padding got broken by c789b981b244333cfc903bcd1e2fefc010500013.
This caused serious performance regression because part of the key was
unitialized and hence the shader always recompiled (at least on release
bui
https://bugs.freedesktop.org/show_bug.cgi?id=59994
--- Comment #1 from LoneVVolf ---
FYI :
liclcl nor CLANG are installed, LLVM from tstellar tree with amdgpu is present
--
You are receiving this mail because:
You are the assignee for the bug.
___
mes
https://bugs.freedesktop.org/show_bug.cgi?id=59880
Ian Romanick changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Ian Romanick
https://bugs.freedesktop.org/show_bug.cgi?id=59994
Priority: medium
Bug ID: 59994
Assignee: mesa-dev@lists.freedesktop.org
Summary: autogen.sh can't find libclc package
Severity: normal
Classification: Unclassified
OS: Linux
On 01/28/2013 04:11 PM, Stéphane Marchesin wrote:
Check that the return value from xcb_dri2_swap_buffers_reply is
non-NULL before accessing the struct members.
---
src/glx/dri2_glx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_g
On 01/28/2013 02:43 PM, Christoph Bumiller wrote:
On 28.01.2013 23:37, Chad Versace wrote:
On 01/28/2013 02:01 PM, Christoph Bumiller wrote:
From: Christoph Bumiller
Only the test of the extension enable should be relevant.
I don't think this change is correct.
So, maybe I misinterpreted t
Check that the return value from xcb_dri2_swap_buffers_reply is
non-NULL before accessing the struct members.
---
src/glx/dri2_glx.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index a51716f..78a2a42 100644
--- a/src/glx/dri2_
From: Roland Scheidegger
The struct padding got broken by c789b981b244333cfc903bcd1e2fefc010500013.
This caused serious performance regression because part of the key was
unitialized and hence the shader always recompiled (at least on release
builds...).
While here also fix key size calculation w
On 28.01.2013 23:37, Chad Versace wrote:
> On 01/28/2013 02:01 PM, Christoph Bumiller wrote:
>> From: Christoph Bumiller
>>
>> Only the test of the extension enable should be relevant.
> I don't think this change is correct.
So, maybe I misinterpreted the advice in the "mesa: implement
GL_ARB_tex
On 01/28/2013 02:01 PM, Christoph Bumiller wrote:
> From: Christoph Bumiller
>
> Only the test of the extension enable should be relevant.
I don't think this change is correct.
For most extensions, including GL_ARB_texture_buffer_object, the Intel driver
enables the extension flags according on
The BLT engine has many limitations. Currently, it can only blit
X-tiled buffers (since we don't have a kernel API to whack the BLT
tiling mode register), which means all depth/stencil operations get
punted to meta code, which can be very CPU-intensive.
Even if we used the BLT engine, it can't bl
On 01/20/2013 02:15 PM, Paul Berry wrote:
[snip]
As an alternative to those fixes, here's my refactoring suggestion: drop
this function entirely, and instead, in brw_blorp_copytexsubimage(),
create a temporary intel_renderbuffer to wrap around dst_image, and just
call do_blorp_blit() directly. d
From: Christoph Bumiller
Only the test of the extension enable should be relevant.
---
src/mesa/main/teximage.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 31a559e..5a27797 100644
--- a/src/mesa/main/teximag
Committed. Thanks for fixing my bug :)
On 01/25/2013 11:27 PM, Vinson Lee wrote:
> Fixes side effect in assertion defects reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -
https://bugs.freedesktop.org/show_bug.cgi?id=59877
--- Comment #9 from Tom Stellard ---
(In reply to comment #8)
> Created attachment 73796 [details] [review]
> v2: Right attempt to fix it on current master
>
> It shouldn't fail because of:
>
> if USE_R600_LLVM_COMPILER
> if HAVE_GALLIUM_COMPUT
https://bugs.freedesktop.org/show_bug.cgi?id=59877
Johannes Obermayr changed:
What|Removed |Added
Attachment #73792|0 |1
is obsolete|
On 01/28/2013 12:58 PM, Chad Versace wrote:
> On 01/23/2013 11:56 PM, Tapani Pälli wrote:
>> Hello;
>>
>> Following patch introduces API change between Mesa and gralloc module.
>> Gralloc
>> module with appropriate change is available at 01.org Android repository.
>> This
>> change is not compati
On 01/23/2013 11:56 PM, Tapani Pälli wrote:
> Hello;
>
> Following patch introduces API change between Mesa and gralloc module. Gralloc
> module with appropriate change is available at 01.org Android repository. This
> change is not compatible with current android-x86 project gralloc. As this
> k
On 01/23/2013 11:56 PM, Tapani Pälli wrote:
> currently a gralloc internal structure is exposed to mesa,
> use a query function instead to maintain ABI compatibility.
>
> Signed-off-by: Tapani Pälli
> ---
> src/egl/drivers/dri2/platform_android.c | 8 ++--
> src/egl/main/A
Abdiel Janulgue writes:
> - Rename draw_x/y to tile_x/y in dri image struct. These are now used as
> adjustment pixels from our stored aligned offset to the exported image
> instead of the entire x/y offset from the base address.
> - Take into consideration the offset from our bo so that sub
On 01/27/2013 01:52 PM, Marek Olšák wrote:
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |4 ++--
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |2 +-
src/mesa/main/format_pack.c | 16
src/mesa/main/format_unpack.c
On 01/28/2013 12:00 PM, Brian Paul wrote:
This and the previous are
Reviewed-by: Ian Romanick
---
src/mesa/drivers/x11/xm_api.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c
index 739e8ac..f237
Christoph Bumiller writes:
> On 28.01.2013 19:54, Ian Romanick wrote:
>> On 01/27/2013 12:19 PM, Eric Anholt wrote:
>>> Christoph Bumiller writes:
>>>
On 27.01.2013 00:58, Eric Anholt wrote:
> Christoph Bumiller writes:
>> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/texim
On 24 January 2013 13:59, Eric Anholt wrote:
> Paul Berry writes:
>
> > Yeah, you're right. I was being lazy. How's this:
>
> > * Furthermore, intelEmitCopyBlit (which is called by
> > * intel_miptree_map_blit) uses a signed 16-bit integer to represent
> > buffer
> > * pitch, so it
https://bugs.freedesktop.org/show_bug.cgi?id=59877
Tom Stellard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 01/28/2013 12:10 PM, jfons...@vmware.com wrote:
From: José Fonseca
Simply by adjusting the vector element width after/before
reading/writing the depth-stencil values.
Ran several GL_DEPTH_COMPONENT16 piglit tests without regressions.
---
src/gallium/drivers/llvmpipe/lp_bld_depth.c | 46 +
---
src/mesa/drivers/x11/xm_api.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c
index 739e8ac..f23755e 100644
--- a/src/mesa/drivers/x11/xm_api.c
+++ b/src/mesa/drivers/x11/xm_api.c
@@ -928,13 +928,12
On 01/28/2013 11:56 AM, Ian Romanick wrote:
On 01/28/2013 10:46 AM, Brian Paul wrote:
---
src/mesa/drivers/x11/xm_api.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_api.c
b/src/mesa/drivers/x11/xm_api.c
index 5931f5b..739e8ac 100644
--- a/src/mes
https://bugs.freedesktop.org/show_bug.cgi?id=59877
--- Comment #6 from Johannes Obermayr ---
Created attachment 73792
--> https://bugs.freedesktop.org/attachment.cgi?id=73792&action=edit
Right attempt to fix it on current master
--
You are receiving this mail because:
You are the assignee for
On 28.01.2013 19:54, Ian Romanick wrote:
> On 01/27/2013 12:19 PM, Eric Anholt wrote:
>> Christoph Bumiller writes:
>>
>>> On 27.01.2013 00:58, Eric Anholt wrote:
Christoph Bumiller writes:
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 31a559e..e71f6e1 10
From: José Fonseca
Simply by adjusting the vector element width after/before
reading/writing the depth-stencil values.
Ran several GL_DEPTH_COMPONENT16 piglit tests without regressions.
---
src/gallium/drivers/llvmpipe/lp_bld_depth.c | 46 ---
src/gallium/drivers/llvmp
On 01/26/2013 05:39 AM, Marek Olšák wrote:
On Sat, Jan 26, 2013 at 3:16 AM, Matt Turner wrote:
On Fri, Jan 25, 2013 at 6:02 PM, Marek Olšák wrote:
These extensions are not new in Mesa:
- ARB_base_instance (since 9.0)
- ARB_vertex_type_2_10_10_10_rev (since 8.0)
- OES_standard_derivatives (sin
On 01/28/2013 10:46 AM, Brian Paul wrote:
---
src/mesa/drivers/x11/xm_api.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c
index 5931f5b..739e8ac 100644
--- a/src/mesa/drivers/x11/xm_api.c
+++ b/src/mesa/
https://bugs.freedesktop.org/show_bug.cgi?id=59967
--- Comment #5 from Matt Turner ---
http://www.gnu.org/software/autoconf-archive/ax_ext_have_lib.html looks like a
potential solution.
--
You are receiving this mail because:
You are the assignee for the bug.
__
On 01/27/2013 12:19 PM, Eric Anholt wrote:
Christoph Bumiller writes:
On 27.01.2013 00:58, Eric Anholt wrote:
Christoph Bumiller writes:
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 31a559e..e71f6e1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage
https://bugs.freedesktop.org/show_bug.cgi?id=59967
--- Comment #4 from Michel Dänzer ---
(In reply to comment #3)
> There are AC_CHECK_LIB and AC_SEARCH_LIBS macros, but there doesn't seem to be
> a way to pass extra library paths to it, so I think this would fail if the
> shared objects were not
---
src/mesa/drivers/x11/xm_api.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c
index 5931f5b..739e8ac 100644
--- a/src/mesa/drivers/x11/xm_api.c
+++ b/src/mesa/drivers/x11/xm_api.c
@@ -929,7 +929,8 @@ XMesa
We never really have multisampling with one sample per pixel.
See also http://bugs.freedesktop.org/show_bug.cgi?id=59873
Note: This is a candidate for the 9.0 branch.
---
src/mesa/state_tracker/st_extensions.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/mesa/st
Note: This is a candidate for the 9.0 branch.
---
src/mesa/main/extensions.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 7ae07fb..7a8195a 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extension
https://bugs.freedesktop.org/show_bug.cgi?id=59967
--- Comment #3 from Tom Stellard ---
(In reply to comment #1)
> (In reply to comment #1)
> > Full build log here:
> > https://launchpadlibrarian.net/129750443/buildlog_ubuntu-quantal-i386.mesa_9.
> > 1~git1301281053.87592c~gd~q_FAILEDTOBUILD.txt.
On 28 January 2013 09:00, Brian Paul wrote:
> On Mon, Jan 28, 2013 at 9:17 AM, Marek Olšák wrote:
> > On Mon, Jan 28, 2013 at 4:54 PM, Brian Paul wrote:
> >> [cross-posting this reply to the mesa-dev list]
> >>
> >>
> >> On 01/27/2013 09:07 AM, Brian Paul wrote:
> >>>
> >>> On Sun, Jan 27, 2013
https://bugs.freedesktop.org/show_bug.cgi?id=59967
Michel Dänzer changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTOURBUG
https://bugs.freedesktop.org/show_bug.cgi?id=59967
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Jan 28, 2013 at 6:18 PM, Brian Paul wrote:
> On 01/27/2013 06:52 PM, Marek Olšák wrote:
>>
>> Module: Mesa
>> Branch: master
>> Commit: 87592cff57feef29565150b9203e220b50623f30
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=87592cff57feef29565150b9203e220b50623f30
>>
>> Author
On 01/27/2013 06:52 PM, Marek Olšák wrote:
Module: Mesa
Branch: master
Commit: 87592cff57feef29565150b9203e220b50623f30
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=87592cff57feef29565150b9203e220b50623f30
Author: Marek Olšák
Date: Mon Jan 28 02:47:24 2013 +0100
gallium/u_upload_
On Mon, Jan 28, 2013 at 9:17 AM, Marek Olšák wrote:
> On Mon, Jan 28, 2013 at 4:54 PM, Brian Paul wrote:
>> [cross-posting this reply to the mesa-dev list]
>>
>>
>> On 01/27/2013 09:07 AM, Brian Paul wrote:
>>>
>>> On Sun, Jan 27, 2013 at 2:51 AM, Eric Anholt wrote:
Brian Paul writes:
Reviewed-by: Marek Olšák
Marek
On Mon, Jan 28, 2013 at 4:55 PM, wrote:
> From: Alex Deucher
>
> It shouldn't be needed and older kernels don't support
> it.
>
> v2: Replace with PS partial flush as before.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=59945
>
> Signed-off-by: Alex
On Mon, Jan 28, 2013 at 4:54 PM, Brian Paul wrote:
> [cross-posting this reply to the mesa-dev list]
>
>
> On 01/27/2013 09:07 AM, Brian Paul wrote:
>>
>> On Sun, Jan 27, 2013 at 2:51 AM, Eric Anholt wrote:
>>>
>>> Brian Paul writes:
>>>
Even if GL_ARB_multisample is advertised, it's OK for
[cross-posting this reply to the mesa-dev list]
On 01/27/2013 09:07 AM, Brian Paul wrote:
On Sun, Jan 27, 2013 at 2:51 AM, Eric Anholt wrote:
Brian Paul writes:
Even if GL_ARB_multisample is advertised, it's OK for the max number of
samples to be zero.
Huh? The EXT_framebuffer_multisampl
From: Alex Deucher
It shouldn't be needed and older kernels don't support
it.
v2: Replace with PS partial flush as before.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=59945
Signed-off-by: Alex Deucher
---
src/gallium/drivers/r600/r600_hw_context.c | 37 +---
v2: fix compilation of swrast
---
src/mesa/main/format_pack.c | 186 ++
src/mesa/main/format_unpack.c | 297 +
src/mesa/main/formats.c | 207
src/mesa/main/formats.h | 16 +++
src/mesa/m
Sorry, I don't build swrast and I incorrectly assumed that adding new
formats which swrast doesn't use wouldn't break compiling. I didn't
update _mesa_choose_tex_format, because it's not part of the vertical
slice I'm implementing.
I'll send a corrected patch shortly.
Marek
On Mon, Jan 28, 2013
On Don, 2013-01-24 at 13:46 +0100, Christian König wrote:
> From: Christian König
>
> The loop handling in the CFG structurizer incorrectly assumed
> that only BasicBlock nodes can have a back edge, but that is
> also possible for the exit edges of subregions.
>
> Fixing 4 more piglit tests on
Am 26.01.2013 18:26, schrieb Daniel Vetter:
> On Fri, Jan 25, 2013 at 11:03:35PM -0800, Kenneth Graunke wrote:
>> On 01/25/2013 03:13 PM, Roland Scheidegger wrote:
>>> I'm quite sure there are g965 boards around which indeed support Pentium
>>> 4 (and P4-based Celerons) (but yes I guess cmov and at
On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote:
> I've been looking at untangling the pixel format code for big-endian.
> My current theory is that blindly byte-swapping values is just wrong.
Certainly. :) I think you're discovering that this hasn't really been
thought through beyond what'
https://bugs.freedesktop.org/show_bug.cgi?id=59879
--- Comment #2 from José Fonseca ---
Ignore the "lib32" above. I meant "lib"
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=59879
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #1 from J
Thanks Roland.
I'd do s/texture_unit/resource_unit/g, as buffers bindings are/will be
accepted. Either way:
Reviewed-by: Jose Fonseca
Jose
- Original Message -
> From: Roland Scheidegger
>
> Make it obvious what "unit" this is (no change in functionality).
> draw still uses "unit" i
I've been looking at untangling the pixel format code for big-endian.
My current theory is that blindly byte-swapping values is just wrong.
Data coming from the application is never in the "wrong" order.
Consider the first non-trivial format emitted in u_format_table.c:
/* taken from an x86 bu
https://bugs.freedesktop.org/show_bug.cgi?id=59967
Priority: medium
Bug ID: 59967
CC: tstel...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [regression] configure: error: Could not find llvm
shared librar
Tapani Pälli writes:
> Signed-off-by: Tapani Pälli
Reviewed-by: Eric Anholt
pgpyvjRe5kwE1.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
89 matches
Mail list logo
