From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/r300/r300_query.c | 2 +-
src/gallium/drivers/r300/r300_render.c| 2 +-
src/gallium/drivers/r300/r300_screen_buffer.c | 4 ++--
From: Michel Dänzer michel.daen...@amd.com
Should reduce overhead because the caching buffer manager doesn't need to
consider buffers of the wrong type.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 10 +++---
In order to try and improve X(Shm)PutImage performance with glamor, I
implemented support for write-combined CPU mappings of BOs in GTT.
This did provide a nice speedup, but to my surprise, using VRAM instead
of write-combined GTT turned out to be even faster in general on my
Kaveri machine, both
From: Michel Dänzer michel.daen...@amd.com
This is hopefully safe: The kernel makes sure writes to these mappings
finish before the GPU might start reading from them, and the GPU caches
are invalidated at the start of a command stream.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
drivers/gpu/drm/radeon/r100.c| 2 +-
drivers/gpu/drm/radeon/r300.c| 12 +---
drivers/gpu/drm/radeon/radeon.h | 12 +---
drivers/gpu/drm/radeon/radeon_asic.h |
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/r600_buffer_common.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
drivers/gpu/drm/radeon/cik.c | 3 +++
drivers/gpu/drm/radeon/cik_sdma.c| 2 ++
drivers/gpu/drm/radeon/ni.c | 3 +++
drivers/gpu/drm/radeon/ni_dma.c | 2 ++
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
drivers/gpu/drm/radeon/cik.c | 4 ++--
drivers/gpu/drm/radeon/cik_sdma.c | 3 ++-
drivers/gpu/drm/radeon/evergreen.c| 12
drivers/gpu/drm/radeon/r600.c
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
drivers/gpu/drm/radeon/cik.c | 3 +++
drivers/gpu/drm/radeon/cik_sdma.c| 4
drivers/gpu/drm/radeon/ni.c | 3 +++
drivers/gpu/drm/radeon/ni_dma.c | 4
From: Michel Dänzer michel.daen...@amd.com
Doesn't seem necessary, the GART table memory should be persistent.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
drivers/gpu/drm/radeon/cik.c | 1 -
drivers/gpu/drm/radeon/evergreen.c | 1 -
drivers/gpu/drm/radeon/ni.c |
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeon/r600_buffer_common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
Am 17.07.2014 12:01, schrieb Michel Dänzer:
In order to try and improve X(Shm)PutImage performance with glamor, I
implemented support for write-combined CPU mappings of BOs in GTT.
This did provide a nice speedup, but to my surprise, using VRAM instead
of write-combined GTT turned out to be
On 17.07.2014 12:01, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
This is hopefully safe: The kernel makes sure writes to these mappings
finish before the GPU might start reading from them, and the GPU caches
are invalidated at the start of a command stream.
Aren't CPU
The patch is wrong. is_rtt is only set for textures, not
renderbuffers, so it breaks rendering to depth renderbuffers.
Marek
On Thu, Jul 17, 2014 at 12:02 AM, David Weber weber.aulend...@gmail.com wrote:
Hi,
GPU: Radeon HD 5770
mesa: 10.2.2 with gallium/llvm backend
llvm: 3.4.2
linux:
The resource flags actually tell you what you can do. If the COHERENT
flag is set, the mapping must be cached. If it's unset, it's up to
you.
If write-combining is faster for vertex uploads, then Glamor shouldn't
set the coherent flag.
Marek
On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer
Tom Stellard thomas.stell...@amd.com writes:
v2:
- Move the end_query() call into the timestamp constructor.
- Still pass false as the wait parameter to get_query_result().
Reviewed-by: Francisco Jerez curroje...@riseup.net
---
src/gallium/state_trackers/clover/core/timestamp.cpp | 1
Like I said at patch 4, this would be okay if the COHERENT flag wasn't set.
If you removed the PERSISTENT flag from the conditional, the placement
of persistent non-coherent buffers would be driven by the usage,
meaning that you would be able to get any kind of placement you want.
Marek
On Thu,
Tom Stellard thomas.stell...@amd.com writes:
We use PIPE_QUERY_TIMESTAMP for profiling events, and gallium specifies
that the timestamp be in nanoseconds.
---
src/gallium/state_trackers/clover/api/device.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer mic...@daenzer.net wrote:
Mesa patches:
[PATCH 1/5] winsys/radeon: Use separate caching buffer managers for
[PATCH 2/5] r600g/radeonsi: Use write-combined CPU mappings of some
[PATCH 3/5] r600g/radeonsi: Prefer VRAM for CPU - GPU streaming
For
On Thu, Jul 17, 2014 at 6:01 AM, Michel Dänzer mic...@daenzer.net wrote:
In order to try and improve X(Shm)PutImage performance with glamor, I
implemented support for write-combined CPU mappings of BOs in GTT.
This did provide a nice speedup, but to my surprise, using VRAM instead
of
On Thu, 17 Jul 2014, Eero Tamminen wrote:
While effect of unaligned accesses is normally invisible,
No, the compiler is inserting padding here silently.
We call this “implicit padding”. The problem with it
is that this padding is architecture-dependent, and
some platforms have other alignment
On Thu, Jul 17, 2014 at 4:21 AM, Thorsten Glaser t.gla...@tarent.de wrote:
On Thu, 17 Jul 2014, Eero Tamminen wrote:
While effect of unaligned accesses is normally invisible,
No, the compiler is inserting padding here silently.
We call this “implicit padding”. The problem with it
[ strip
On Thu, 2014-07-17 at 10:21 +0200, Thorsten Glaser wrote:
On Thu, 17 Jul 2014, Eero Tamminen wrote:
While effect of unaligned accesses is normally invisible,
No, the compiler is inserting padding here silently.
We call this “implicit padding”. The problem with it
is that this padding is
On Thu, Jul 17, 2014 at 10:24 AM, Thorsten Glaser t.gla...@tarent.de wrote:
On Thu, 17 Jul 2014, Ilia Mirkin wrote:
Yes, implicit padding is definitely bad. I didn't realize I even had
it in there, although I'm glad my STATIC_ASSERT did its job. There are
;-)
various references to patches,
On Thu, 17 Jul 2014, Ilia Mirkin wrote:
Yes, implicit padding is definitely bad. I didn't realize I even had
it in there, although I'm glad my STATIC_ASSERT did its job. There are
;-)
various references to patches, however I haven't seen any. Perhaps
they're lost in my inbox, or they were
On Thu, 17 Jul 2014, Jan Vesely wrote:
why not use __attribute__ ((aligned(X))) for explicit padding?
That’s ① GCC-specific and ② relies on environmental guarantees
that cannot always be given (e.g. you cannot align a struct
more than the stack alignment if it is ever passed on the
stack; for
Hi Ilia!
On 07/17/2014 04:35 PM, Ilia Mirkin wrote:
Thanks! Munged the commit description a little and pushed to the
master branch. I think the patches for 10.2.4 have already been
selected, so it should make its way into 10.2.5.
Awesome, thank you so much! Glad we could finally this one :).
Hi Mathias,
Thanks for doing this.
Patch 2 looks great.
For patch 1 I'd prefer that instead of keeping a global list of
contexts, these are passed by the caller as argument to gallivm_create()
. It will be a more invasive change, but it will be cleaner. And in
particular it will garantee
According to spec (OpenGL 4.0 specification, pages 254-255) we have a different
bits set
for one buffer and for multiple buffers. For glDrawBuffer we may have up to
four bits set
but for glDrawBuffers we can only have one bit set.
The _mesa_drawbuffers is called with ctx-Const.MaxDrawBuffers
Accuracy of some operations was recently improved in the R600 backend,
at the cost of slower code. This is required for compute shaders,
but not for graphics shaders. Add unsafe-fp-math hint to make LLVM
generate faster but possibly less accurate code.
Piglit didn't indicate any regressions.
---
Use KR and same indent as most other code. No functional change
intended.
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
https://bugs.freedesktop.org/show_bug.cgi?id=80848
--- Comment #8 from Emil Velikov emil.l.veli...@gmail.com ---
Juha-Pekka, Bryan
Can you guys test the patch in comment 7 ? I feel slightly reluctant about
breaking my system in order to test it myself.
--
You are receiving this mail because:
Mesa hasn't supported color-indexed textures for some time. This is 0 for
all texture formats, so we don't need to store it.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/format_info.py | 2 +-
src/mesa/main/formats.c | 3 +--
2 files changed, 2 insertions(+), 3
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/formats.csv | 282 ++
1 file changed, 282 insertions(+)
create mode 100644 src/mesa/main/formats.csv
diff --git a/src/mesa/main/formats.csv b/src/mesa/main/formats.csv
new file
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/format_info.py | 11 +++
src/mesa/main/formats.c | 46
src/mesa/main/formats.h | 29
3 files changed, 86 insertions(+)
diff --git
This is the first installment of some work I've been doing over the past
couple of weeks to refactor mesa's texture conversion/storage code. There
is more to be done and more that I have done but have not included in this
series. This is the first mailing-list-ready fruits of my efforts. The
Before it was only storing one of the color components due to truncation.
With this patch it now properly stores all of them.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/format_pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Most format conversion operations required by GL can be performed by
converting one channel at a time, shuffling the channels around, and
optionally filling missing channels with zeros and ones. This adds a
function to do just that in a general, yet efficient, way.
Signed-off-by: Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 171 +++
1 file changed, 100 insertions(+), 71 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index d363f9f..e1f2284 100644
---
This is a direct helper function for using _mesa_swizzle_and_convert
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/format_utils.c | 93
src/mesa/main/format_utils.h | 4 ++
2 files changed, 97 insertions(+)
diff --git
This initial commit puts all of the RGB - sRGB conversion functions in
one place.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/Makefile.sources| 1 +
src/mesa/main/format_pack.c | 102 ++-
src/mesa/main/format_unpack.c
Again, we delete a lot of functions that aren't really doing anything
interesting anymore.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 545 ++-
1 file changed, 66 insertions(+), 479 deletions(-)
diff --git
This should be both faster and more accurate than our general slow-path of
converting everything to float.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 179 +++
1 file changed, 164 insertions(+), 15 deletions(-)
Otherwise, the performance warning for shader recompiles will just say
something else.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_wm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Wed, Jul 16, 2014 at 3:32 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
The bug is triggered by using glTexSubImage2d() with GL_DEPTH_STENCIL
as base internal format and non-zero x, y offsets. Currently x, y
offsets are ignored while
On Thu, Jul 17, 2014 at 06:44:25PM +0200, Grigori Goronzy wrote:
Accuracy of some operations was recently improved in the R600 backend,
at the cost of slower code. This is required for compute shaders,
but not for graphics shaders. Add unsafe-fp-math hint to make LLVM
generate faster but
Radeonsi was indeed broken with those fixes (only CubeShadow
samplers). The attached patch fixes it. Please add it to 10.2. Thanks.
Marek
On Tue, Jul 15, 2014 at 6:49 AM, Carl Worth cwo...@cworth.org wrote:
Hi folks,
I've pushed out an update to the 10.2 branch and I need some specific
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Thu, Jul 17, 2014 at 11:18 AM, Kenneth Graunke kenn...@whitecape.org wrote:
Otherwise, the performance warning for shader recompiles will just say
something else.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
On Thursday, July 03, 2014 10:13:53 PM Adel Gadllah wrote:
Commit 442442026eb updated both i915 and i965 for DRI3 support,
but one check in intelInitScreen2 was missed for i915 causing crashes
when trying to use i915 with DRI3.
So fix that up.
Reported-by: Igor Gnatenko
Marek Olšák mar...@gmail.com writes:
Radeonsi was indeed broken with those fixes (only CubeShadow
samplers). The attached patch fixes it. Please add it to 10.2. Thanks.
Thanks, Marek!
This is exactly the kind of breakage I was worried about, and exactly
the kind of test reporting I was hoping
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 04cbc4c..4043eb7 100644
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/drivers/dri/i965/intel_tex_image.c| 4 +++-
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 6 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
These two are
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Avoids regenerating it unnecessarily.
Every program in shader-db improved, none by an amount less than a 1/3
reduction. One Dota2 shader decreased from 62 - 24.
cfg calculations: 429492 - 193197 (-55.02%)
---
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 20 +++-
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 4 +++-
src/mesa/drivers/dri/i965/brw_fs.cpp | 10 ++
src/mesa/drivers/dri/i965/brw_fs.h| 12 ++--
src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 22 +-
We'd like to avoid regenerating the control flow graph for every
pass that uses it. This series adds a cfg pointer to the backend
visitor class that we use to save the CFG across optimization
passes. It's invalidated and recreated by invalidate/calculate_cfg
and these functions are called by the
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 5 +
src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 5 +
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 49a4e9b..045e1c5 100644
---
Will let us abstract how the instructions are stored.
---
src/mesa/drivers/dri/i965/brw_cfg.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h
b/src/mesa/drivers/dri/i965/brw_cfg.h
index cdbadde..01fcc1b 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
Use this as an opportunity to rename 'block_num' to 'num'. block-num is
clear, and block-block_num has always been redundant.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 17 ++---
src/mesa/drivers/dri/i965/brw_cfg.h| 5 +-
---
src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_fs_cse.cpp| 7 +++
.../drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 8 +++-
The next patch adds a foreach_block (block, cfg) macro, which works
better if it provides a direct bblock_t pointer, rather than a
bblock_link pointer that you have to use to find the actual block.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 10 +-
src/mesa/drivers/dri/i965/brw_cfg.h |
Juha-Pekka,
The patch I just sent to the list here:
http://lists.freedesktop.org/archives/mesa-dev/2014-July/063501.html
Should also help with chrome performance. We have had a fast-path inside
the intel driver for some time to do BGRA/RGBA - BGRA conversions. For
some reason, chrome seems to
It doesn't exist, so attempting to read it will trigger generation
assertions in the brw_inst API.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_disasm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=79949
Mau mav...@gmail.com changed:
What|Removed |Added
CC||mav...@gmail.com
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=79949
--- Comment #7 from Axel Davy veb...@hotmail.fr ---
It could be solved by this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.2id=3ca21195939477fa1f9b113ce4f6da36a8480321
Please test mesa git or mesa 10.2.3
--
You are receiving
On Thursday, July 17, 2014 02:41:31 PM Jason Ekstrand wrote:
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
Printing the hex offsets makes it basically impossible to diff assembly:
if you add even a single instruction, the entire shader shows up as a
difference. So, every time I want to compare assembly, I have to strip
this out.
The hex offsets might be useful when debugging compaction, or when
On Thu, Jun 26, 2014 at 3:19 PM, Carl Worth cwo...@cworth.org wrote:
Here, skipping refers to the lexer not emitting any tokens for portions of
the file within an #if condition (or similar) that evaluates to false.
Previously, the lexer had a special SKIP start condition used to control
this
Dropping this helps most lines fit in an 80 column terminal. The
absence of WE_normal also helps call attention to WE_all, where
something unusual is going on.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Matt Turner matts...@gmail.com
---
src/mesa/drivers/dri/i965/brw_disasm.c | 2
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Made it ~25% through. :) I'll be busy for a bit, but I'll continue
looking at the rest later.
01/23 glsl/glcpp: Emit proper error for #define with a non-identifier
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
02/23 glsl/glcpp: Add support for comments between #define and macro
We don't want to log every single error (such as all the ones where the file
wasn't even present in our list of search paths), but if you didn't find any
driver, then seeing at least one error is useful (since the common case as a
developer is a single DEFAULT_DRIVER_DIR or GBM_DRIVERS_PATH
I found myself often wanting this when I'm printing out a uint32_t mapping
of some GPU data, and I want to put in an interpretation of that value as
a float.
---
src/gallium/auxiliary/util/u_math.h | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_math.h
---
src/gbm/backends/dri/gbm_dri.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 347bc99..f421a03 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -243,7 +243,7 @@
Here are the patches I have for common code in my vc4 driver tree. I
think they should be obvious enough.
I'm curious what people feel about merging vc4. I've got a series at this
point that's clean enough in my opinion (copyrights fixed up, and I think
a tolerable mix of giant code dump for
Pushed. Thanks.
Marek
On Wed, Jul 16, 2014 at 4:31 PM, Glenn Kennard glenn.kenn...@gmail.com wrote:
Only supported on evergreen and later. Currently limited
to single component textures as the hardware GATHER4
instruction ignores texture swizzles.
Piglit quick run passes on radeon 6670 with
Both patches are
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 18.07.2014 08:56, Eric Anholt wrote:
I found myself often wanting this when I'm printing out a uint32_t mapping
of some GPU data, and I want to put in an interpretation of that value as
a float.
---
src/gallium/auxiliary/util/u_math.h | 8
1 file changed, 8 insertions(+)
diff
Hi Kenneth, Ian,
Could you look through my patch?
Regards,
Pavel
-Original Message-
From: Popov, Pavel E
Sent: Thursday, July 17, 2014 10:21 PM
To: mesa-dev@lists.freedesktop.org
Cc: Popov, Pavel E
Subject: [PATCH] mesa: Correctly use glDrawBuffers for multiple buffers and
https://bugs.freedesktop.org/show_bug.cgi?id=36414
meng mengmeng.m...@intel.com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=36414
--- Comment #12 from meng mengmeng.m...@intel.com ---
As the issue is application's bug, verified it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing
On Wed, Jul 16, 2014 at 11:12:42PM +0200, Bruno Jiménez wrote:
Hi,
This series finally adds support for defragmenting the pool for
OpenCL buffers in the r600g driver. It is mostly a rewritten of
the series that I wrote some months ago.
For defragmenting the pool I have thought of two
https://bugs.freedesktop.org/show_bug.cgi?id=79949
--- Comment #8 from Joseph Booker j...@neoturbine.net ---
Thanks. It doesn't seem to address this. With xf86-video-intel 2.99.912, the
same problem shows with mesa 10.2.3 and mesa master branch (on commit
f14d217f5c72651b9f24a83b11ace16837db4603
On 17.07.2014 19:09, Christian König wrote:
Am 17.07.2014 12:01, schrieb Michel Dänzer:
In order to try and improve X(Shm)PutImage performance with glamor, I
implemented support for write-combined CPU mappings of BOs in GTT.
This did provide a nice speedup, but to my surprise, using VRAM
On 17.07.2014 21:00, Marek Olšák wrote:
On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
This is hopefully safe: The kernel makes sure writes to these mappings
finish before the GPU might start reading from them, and the GPU
Hi Ian,
Looks like this patch is not reasonable for Mesa which now concentrates on
OpenGL 3.3 Core. Am I right?
I prepared this patch to pass Piglit test 'spec_OpenGL_2.0_vs-point_size-zero'
which was created for earlier versions of OpenGL.
Also I found these analogous patches for 'svga',
88 matches
Mail list logo
