Mesa 9.2.5 has been released. Mesa 9.2.5 is a bug fix release which
fixes bugs fixed since the 9.2.4 release, (see below for a list of
changes).
The tag in the git repository for Mesa 9.2.5 is 'mesa-9.2.5'.
Mesa 9.2.5 is available for download at
ftp://freedesktop.org/pub/mesa/9.2.5/
md5sums:
9
Mesa 10.0.1 has been released. Mesa 10.0.1 is a bug fix release which
fixes bugs fixed since the 10.0 release, (see below for a list of
changes).
The tag in the git repository for Mesa 10.0.1 is 'mesa-10.0.1'.
Mesa 10.0.1 is available for download at
ftp://freedesktop.org/pub/mesa/10.0.1/
md5sum
https://bugs.freedesktop.org/show_bug.cgi?id=72619
--- Comment #3 from Vinson Lee ---
The bug can be reproduced with llvm 3.2 and newer.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists
Ah, good stuff, very sensual and does not need more cowbell.
Reviewed-by: Zack Rusin
- Original Message -
> From: Roland Scheidegger
>
> This code was always problematic, and with 64bit rasterization we no longer
> need it at all.
> ---
> src/gallium/drivers/llvmpipe/lp_setup.c
The radeonsi changes in this series are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-d
https://bugs.freedesktop.org/show_bug.cgi?id=72619
--- Comment #2 from Roland Scheidegger ---
Created attachment 90688
--> https://bugs.freedesktop.org/attachment.cgi?id=90688&action=edit
use i8 ptr instead of i32 ptr for load/store of mxcsr
Could you try this patch? Still works with llvm 3.1
On 12/12/2013 05:12 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
This code was always problematic, and with 64bit rasterization we no longer
need it at all.
---
src/gallium/drivers/llvmpipe/lp_setup.c |8 +-
src/gallium/drivers/llvmpipe/lp_setup_context.h |1 -
src
https://bugs.freedesktop.org/show_bug.cgi?id=72659
Priority: medium
Bug ID: 72659
Keywords: regression
CC: jfons...@vmware.com, srol...@vmware.com,
za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Sum
https://bugs.freedesktop.org/show_bug.cgi?id=72658
Priority: medium
Bug ID: 72658
Keywords: regression
CC: jfons...@vmware.com, srol...@vmware.com,
za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Sum
https://bugs.freedesktop.org/show_bug.cgi?id=72657
Priority: medium
Bug ID: 72657
Keywords: regression
CC: jfons...@vmware.com, srol...@vmware.com,
za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Sum
https://bugs.freedesktop.org/show_bug.cgi?id=72656
Priority: medium
Bug ID: 72656
Keywords: regression
CC: jfons...@vmware.com, srol...@vmware.com,
za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Sum
https://bugs.freedesktop.org/show_bug.cgi?id=72655
Vinson Lee changed:
What|Removed |Added
Summary|[llvmpipe] |[llvmpipe] piglit
|arb_co
https://bugs.freedesktop.org/show_bug.cgi?id=72654
Vinson Lee changed:
What|Removed |Added
Summary|[llvmpipe] |[llvmpipe] piglit
|arb_co
https://bugs.freedesktop.org/show_bug.cgi?id=72655
Priority: medium
Bug ID: 72655
Keywords: regression
CC: jfons...@vmware.com, srol...@vmware.com,
za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Sum
https://bugs.freedesktop.org/show_bug.cgi?id=72654
Priority: medium
Bug ID: 72654
Keywords: regression
CC: jfons...@vmware.com, srol...@vmware.com,
za...@vmware.com
Assignee: mesa-dev@lists.freedesktop.org
Sum
From: Roland Scheidegger
This code was always problematic, and with 64bit rasterization we no longer
need it at all.
---
src/gallium/drivers/llvmpipe/lp_setup.c |8 +-
src/gallium/drivers/llvmpipe/lp_setup_context.h |1 -
src/gallium/drivers/llvmpipe/lp_setup_tri.c | 174 ---
Chí-Thanh Christopher Nguyễn writes:
> This fixes building against the new API in X server 1.15
> Taken from xf86-video-modesetting
> beca4dfb0e4d11d3729214967a1fe56ee5669831 from Keith Packard
Thanks. I've cherry-picked this over to 9.2. If no issues are found in
testing, this should appear in
This patch changes the error condition to satisfy below statement
from OpenGL 4.3 core specification:
"An INVALID_OPERATION error is generated if id is the name of a query
object with a target other SAMPLES_PASSED, ANY_SAMPLES_PASSED, or
ANY_SAMPLES_PASSED_CONSERVATIVE, or if id is the name of a qu
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 25ca5d4..e410870 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/s
Found while tracking down memory leaks in VDPAU playback
---
src/gallium/drivers/r600/r600_pipe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 4016bbe..74e007b 100644
--- a/src/gallium/drivers/r600/r600_pip
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
b/src/gallium/drivers/radeon/radeon_llvm_util.c
index cf6d21e..2ace91f 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_util.c
+++ b/src/gallium/d
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 3f50317..e826669 100644
--- a/src/gallium/state_trackers/clover/llvm/inv
Prevents a potential memory leak found when tracking down something else.
---
src/gallium/state_trackers/vdpau/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/vdpau/device.c
b/src/gallium/state_trackers/vdpau/device.c
index 309fee4..fb9c68c 100644
--- a/src
---
src/gallium/drivers/r600/evergreen_compute.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index f0f537c..25ca5d4 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/d
Previously we were creating a new LLVMContext every time that we called
radeon_llvm_parse_bitcode, which caused us to leak the context every time
that we compiled a CL program.
Sadly, we can't dispose of the LLVMContext at the point that it was being
created because evergreen_launch_grid (and poss
Most of these fixes target radeon (both EG and SI), but some also help
clover, pipe loader, and also vdpau playback.
These have been tested mostly on evergreen, but I've had them running
on my desktop (pitcairn) for a few weeks as well.
Aaron Watry (8):
clover: Remove unused variable
pipe_loa
Prevents a memory leak.
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
index c2b78c6..382e116 100644
--- a/src/ga
if defined(_WIN32) && !defined(APIENTRY) && !defined(__CYGWIN__) &&
!defined(__SCITECH_SNAP__)
@@ -53,7 +53,7 @@ extern "C" {
#define GLAPI extern
#endif
-#define GL_GLEXT_VERSION 20131008
+#define GL_GLEXT_VERSION 20131212
/* Generated C header for:
* API
On 11/26/2013 12:02 AM, Francisco Jerez wrote:
[snip]
> + add_image_function("imageLoad",
> + image_builtin_builder(*this)
> + .emit_stub("__intrinsic_image_load")
> + .has_return()
> + .has_vector_data_type()
> +
On 12/12/2013 11:00 AM, Marek Olšák wrote:
From: Marek Olšák
For scaled resolve. The filter is only good for magnification.
If somebody has an idea how to implement a good filter for minification,
I'm all ears. I'd have to use derivatives probably.
Patches 1-5 look good to me.
Reviewed-by:
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #9 from org.freedesk...@io7m.com ---
It actually came from an OS package with these options (no patches are applied
to Mesa):
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa
So yes, gallium
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #8 from Marek Olšák ---
Did you build Mesa with --enable-gallium-egl? If yes, please turn it off and
try again.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #7 from org.freedesk...@io7m.com ---
Probably worth changing the title of this bug if it does turn out that ES3 and
ES2 are fully compatible, and if it's actually possible to change bug titles...
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=72600
--- Comment #6 from org.freedesk...@io7m.com ---
I think the main issue here is that the ES3 context doesn't actually correctly
identify itself as such. As described in the JOGL tracker, the problem is that
JOGL first requests an ES2 context (and
From: Marek Olšák
This advertises GL_ARB_texture_buffer_object_rgb32.
---
src/gallium/drivers/r600/r600_formats.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/r600/r600_formats.h
b/src/gallium/drivers/r600/r600_formats.h
index 453c2b1..fa374d9 100644
--- a/src/gallium
From: Marek Olšák
For scaled resolve. The filter is only good for magnification.
If somebody has an idea how to implement a good filter for minification,
I'm all ears. I'd have to use derivatives probably.
---
src/gallium/auxiliary/util/u_blitter.c| 79 +-
src/galliu
From: Marek Olšák
We need this for integer formats and upside-down blits, which Radeons don't
support for MSAA resolving.
It can be used by calling util_blitter_blit.
---
src/gallium/auxiliary/util/u_blitter.c| 116 +-
src/gallium/auxiliary/util/u_simple_shaders.
From: Marek Olšák
This fixes some MSAA integer tests.
---
src/gallium/drivers/r600/r600_blit.c | 117 +++
1 file changed, 35 insertions(+), 82 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 3fb4d3b..7e
From: Marek Olšák
---
src/gallium/auxiliary/util/u_blitter.c | 24 ++--
src/gallium/auxiliary/util/u_blitter.h | 11 +++
src/gallium/drivers/i915/i915_resource_texture.c | 3 +--
src/gallium/drivers/i915/i915_surface.c | 5 ++---
src/gal
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state.c | 44
src/gallium/drivers/radeonsi/si_state_draw.c | 13
2 files changed, 26 insertions(+), 31 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeon
From: Marek Olšák
---
src/mesa/state_tracker/st_cb_clear.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
b/src/mesa/state_tracker/st_cb_clear.c
index 887e58b..46f2f8d 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/
From: Marek Olšák
This fixes MSAA resolving for 32-bit integer colorbuffers, which isn't
implemented by the hardware.
It also fixes VM protection faults when resolving MSAA 2D array textures.
This may be a CB bug, because shader-based resolving works fine.
It may also be faster for upside-down
From: Marek Olšák
---
.../state_trackers/dri/common/dri_drawable.c | 25 --
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index f255108..a399938
Pushed, thanks.
Marek
On Thu, Dec 12, 2013 at 12:17 AM, Andreas Hartmetz wrote:
> Here:
> git://anongit.kde.org/scratch/ahartmetz/mesa.git
>
> On Wednesday 11 December 2013 20:23:58 Marek Olšák wrote:
>> This looks good to me. Can you send me a git link pointing to all your
>> patches?
>>
>> Mar
Paul Berry writes:
> On 11 December 2013 13:59, Paul Berry wrote:
>
>> On 26 November 2013 00:08, Francisco Jerez wrote:
>>
>>> ---
>>> src/mesa/main/uniform_query.cpp | 36
>>> 1 file changed, 36 insertions(+)
>>>
>>> diff --git a/src/mesa/main/uniform_que
Paul Berry writes:
>[...]
> I see a few downsides to this approach:
>
> - There is unnecessary code duplication between
> builtin_builder::create_intrinsics() and
> builtin_builder::create_builtins(). Both of them create the same set of
> functions using the same parameters, with the only differ
On Mon, Dec 9, 2013 at 3:09 PM, Paul Berry wrote:
> On 7 December 2013 07:42, Francisco Jerez wrote:
>
>> Paul Berry writes:
>>
>> > On 24 November 2013 21:00, Francisco Jerez
>> wrote:
>> >
>> >> Including pack/unpack and texstore code. This texture format is a
>> >> requirement for ARB_shad
Paul Berry writes:
> On 26 November 2013 00:08, Francisco Jerez wrote:
>
>> ---
>> src/mesa/main/uniform_query.cpp | 36
>> 1 file changed, 36 insertions(+)
>>
>> diff --git a/src/mesa/main/uniform_query.cpp
>> b/src/mesa/main/uniform_query.cpp
>> index 88ad
Paul Berry writes:
> On 26 November 2013 00:02, Francisco Jerez wrote:
>
>> ---
>> src/glsl/link_uniforms.cpp | 13 +++-
>> src/glsl/linker.cpp| 50
>> ++
>> 2 files changed, 62 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/glsl/
Paul Berry writes:
> On 26 November 2013 00:02, Francisco Jerez wrote:
>
>>
>> +enum glsl_image_dim {
>> + GLSL_IMAGE_DIM_1D,
>> + GLSL_IMAGE_DIM_2D,
>> + GLSL_IMAGE_DIM_3D,
>> + GLSL_IMAGE_DIM_RECT,
>> + GLSL_IMAGE_DIM_CUBE,
>> + GLSL_IMAGE_DIM_BUFFER,
>> + GLSL_IMAGE_DIM_MS
>> +}
On 12/12/2013 05:14 AM, Pi Tabred wrote:
I incorporated all hints except for the one regarding the malloc, not
sure about this one.
There is still the issue regarding the following:
According to the spec, it should be possible to clear some part of a
buffer, even if a different, non-overlapping
On 12/11/2013 02:05 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/attrib.c | 227 +++--
1 file changed, 144 insertions(+), 83 deletions(-)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 8779
On 12/12/2013 02:49 AM, Pi Tabred wrote:
On 12.12.2013 01:39, Brian Paul wrote:
On 12/11/2013 02:55 PM, Pi Tabred wrote:
- _mesa_buffer_clear_subdata: default callback for dd function table
- _mesa_ClearBufferData: API function
- _mesa_ClearBufferSubData: API function
- buffer_obj
On 12/12/2013 02:42 AM, Pi Tabred wrote:
On 12.12.2013 01:39, Brian Paul wrote:
On 12/11/2013 02:55 PM, Pi Tabred wrote:
- add xml file for extension
- add reference in gl_API.xml
- add pointer to device driver function table
- add new functions to list of available functions
Or
On 12/12/2013 02:19 AM, Juha-Pekka Heikkilä wrote:
On Thu, Dec 12, 2013 at 3:14 AM, Brian Paul wrote:
On 12/11/2013 02:05 AM, Juha-Pekka Heikkila wrote:
Change save_attrib_data() to return true/false depending on success.
Signed-off-by: Juha-Pekka Heikkila
I'd like to reconsider these ch
On 12/11/2013 02:05 AM, Juha-Pekka Heikkila wrote:
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/attrib.c | 227 +++--
1 file changed, 144 insertions(+), 83 deletions(-)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index 8779
---
src/gallium/drivers/r600/r600_asm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 86f79e2..c5922a8 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@
https://bugs.freedesktop.org/show_bug.cgi?id=68296
U. Artie Eoff changed:
What|Removed |Added
CC||ullysses.a.e...@intel.com
--
You are re
https://bugs.freedesktop.org/show_bug.cgi?id=68296
U. Artie Eoff changed:
What|Removed |Added
Severity|normal |major
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #5 from U. Artie Eoff ---
Any progress made on a resolution?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=67676
Pekka Paalanen changed:
What|Removed |Added
CC||ppaala...@gmail.com
--- Comment #2 from
I incorporated all hints except for the one regarding the malloc, not
sure about this one.
There is still the issue regarding the following:
According to the spec, it should be possible to clear some part of a
buffer, even if a different, non-overlapping part is mapped, this is
currently not possi
On 12.12.2013 01:39, Brian Paul wrote:
> On 12/11/2013 02:55 PM, Pi Tabred wrote:
>> - _mesa_buffer_clear_subdata: default callback for dd function table
>> - _mesa_ClearBufferData: API function
>> - _mesa_ClearBufferSubData: API function
>> - buffer_object_format_good: helper function, c
On 12.12.2013 01:39, Brian Paul wrote:
> On 12/11/2013 02:55 PM, Pi Tabred wrote:
>> - add xml file for extension
>> - add reference in gl_API.xml
>> - add pointer to device driver function table
>> - add new functions to list of available functions
>
> Or "- update dispatch_sanity.cpp"
The kernel doesn't even set up the aliasing PPGTT on Sandybridge, so any
writes marked as PPGTT will likely just get dropped on the floor.
This begs the question: is the simple act of /requesting/ a write good
enough for the workaround, or does it need to actually work? Past
experience suggests t
Now that we have a helper function that handles the PIPE_CONTROL
variations between the various platforms, these are basically the same.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_queryobj.c | 12 +++-
src/mesa/driv
There are a lot of places that use PIPE_CONTROL to write a value to a
buffer (either an immediate write, TIMESTAMP, or PS_DEPTH_COUNT).
Creating a single function to do this seems convenient.
As part of this refactor, we now set the PPGTT/GTT selection bit
correctly on Gen7+. Previously, we set b
These days, we need to emit PIPE_CONTROL flushes all over the place.
Being able to do that via a single function call seems convenient.
Broadwell will also increase the length of these packets by 1; with the
refactoring, we should have to do this in substantially fewer places.
Signed-off-by: Kenn
Broadwell uses 48-bit addresses. The first DWord is the low 32 bits,
and the second DWord is the high 16 bits.
Since individual buffers shouldn't be larger than 4GB in size, any
offsets into those buffers (buffer->offset + delta) should fit in the
low 32 bits. So I believe we can simply emit 0 f
brw_queryobj.c needs a version of write_timestamp that works on all
generations for the QueryCounter() driver hook. So there's no point in
duplicating it in gen6_queryobj.c.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_queryo
I believe that PIPE_CONTROL uses the length field to decide whether to
do 32-bit or 64-bit writes. A length of 4 would do a 32-bit write,
while a length of 5 would do a 64-bit write. (I haven't verified this,
though.)
For workaround writes, we don't care what value gets written, or how
much data
On Broadwell, PIPE_CONTROL needs an extra DWord to accomodate the
48-bit addressing.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchb
The PIPE_CONTROL packet actually has 5 DWords on Gen6+:
1. Header
2. Flags
3. Address
4. Immediate Data: Lower DWord
5. Immediate Data: Upper DWord
We just never emitted the last one. While it appears to work, it's
probably safer to emit the entire thing.
Signed-off-by: Kenneth Graunke
---
src
Both brw_defines.h and intel_reg.h defined PIPE_CONTROL fields, which
had similar names, but couldn't be used in the same way. (One had
built-in shifts, and the other didn't...)
Delete the unused set to preserve sanity.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h
On Thu, Dec 12, 2013 at 3:14 AM, Brian Paul wrote:
> On 12/11/2013 02:05 AM, Juha-Pekka Heikkila wrote:
>>
>> Change save_attrib_data() to return true/false depending on success.
>>
>> Signed-off-by: Juha-Pekka Heikkila
>
>
> I'd like to reconsider these changes from scratch.
>
> The basic issue
75 matches
Mail list logo
