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', 'r30
On 17.07.2014 21:00, Marek Olšák wrote:
> On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> 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
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 V
https://bugs.freedesktop.org/show_bug.cgi?id=79949
--- Comment #8 from Joseph Booker ---
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 ).
If it helps, the
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 tw
https://bugs.freedesktop.org/show_bug.cgi?id=36414
--- Comment #12 from meng ---
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 list
mesa-dev@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=36414
meng changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are receiving this mail because:
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
glDrawBuffer
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(+)
>
Both patches are
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Pushed. Thanks.
Marek
On Wed, Jul 16, 2014 at 4:31 PM, Glenn Kennard 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 all
> applicable t
---
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 @@ dri_loa
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 st
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 entry).
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
b/s
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
02/23 glsl/glcpp: Add support for comments between #define and macro identifier
Reviewed-by: Jordan J
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/brw_disasm.c | 2 +-
1 file changed, 1 insertion(+), 1 de
On Thu, Jun 26, 2014 at 3:19 PM, Carl Worth 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 start condition used to control
> this skipping. This
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
inspec
On Thursday, July 17, 2014 02:41:31 PM Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> 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/i
https://bugs.freedesktop.org/show_bug.cgi?id=79949
--- Comment #7 from Axel Davy ---
It could be solved by this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.2&id=3ca21195939477fa1f9b113ce4f6da36a8480321
Please test mesa git or mesa 10.2.3
--
You are receiving this mail because:
Y
https://bugs.freedesktop.org/show_bug.cgi?id=79949
Mau changed:
What|Removed |Added
CC||mav...@gmail.com
--
You are receiving this mail b
It doesn't exist, so attempting to read it will trigger generation
assertions in the brw_inst API.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_disasm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mes
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
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 +-
.../drivers/dri/i965/brw_dead_control_flow.
---
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 +++-
src/mesa/drivers/dr
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
+
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 |
---
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
--- a/src/me
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 +-
src/mesa/drivers/d
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 si
These two are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Signed-off-by: Jason Ekstrand
---
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
--- a/src/mesa/drivers/dr
Signed-off-by: Jason Ekstrand
---
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
b/src/mesa/drivers/dri/i965/intel_tex_im
Marek Olšák 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 for. So thanks,
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
> Tested-by
Reviewed-by: Jordan Justen
On Thu, Jul 17, 2014 at 11:18 AM, Kenneth Graunke wrote:
> Otherwise, the performance warning for shader recompiles will just say
> "something else".
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_wm.c | 2 ++
> 1 file changed, 2 insertions(
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 wrote:
> Hi folks,
>
> I've pushed out an update to the 10.2 branch and I need some specific
> testing in the next
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 po
Reviewed-by: Jordan Justen
On Wed, Jul 16, 2014 at 3:32 PM, Anuj Phogat 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 updating the texture image.
>
> Fixes Khronos GLE
Otherwise, the performance warning for shader recompiles will just say
"something else".
Signed-off-by: Kenneth Graunke
---
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
b/src/mesa/drivers/dri/i965/brw_wm.c
index d716
This initial commit puts all of the RGB <-> sRGB conversion functions in
one place.
Signed-off-by: Jason Ekstrand
---
src/mesa/Makefile.sources| 1 +
src/mesa/main/format_pack.c | 102 ++-
src/mesa/main/format_unpack.c| 69 -
This should be both faster and more accurate than our general slow-path of
converting everything to float.
Signed-off-by: Jason Ekstrand
---
src/mesa/main/texstore.c | 179 +++
1 file changed, 164 insertions(+), 15 deletions(-)
diff --git a/src/mesa/m
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
---
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
--- a/src/mesa/main/texstore.c
+++ b
This is a direct helper function for using _mesa_swizzle_and_convert
Signed-off-by: Jason Ekstrand
---
src/mesa/main/format_utils.c | 93
src/mesa/main/format_utils.h | 4 ++
2 files changed, 97 insertions(+)
diff --git a/src/mesa/main/format_utils.
Again, we delete a lot of functions that aren't really doing anything
interesting anymore.
Signed-off-by: Jason Ekstrand
---
src/mesa/main/texstore.c | 545 ++-
1 file changed, 66 insertions(+), 479 deletions(-)
diff --git a/src/mesa/main/texstore.c b
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
---
src/mesa/main/format_pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/format_pack.c b/src/mesa/m
Signed-off-by: Jason Ekstrand
---
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 a/src/mesa/main/format_inf
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
imp
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
---
src/mesa/main/format_info.py | 2 +-
src/mesa/main/formats.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Jason Ekstrand
---
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 mode 100644
index 000.
https://bugs.freedesktop.org/show_bug.cgi?id=80848
--- Comment #8 from Emil Velikov ---
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:
You are the assignee for t
Use K&R 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
b/src/gallium/drivers/radeon/ra
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.
---
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 an
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 t
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 s
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 :)
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 wer
On Thu, Jul 17, 2014 at 10:24 AM, Thorsten Glaser 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, however
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 padd
On Thu, Jul 17, 2014 at 4:21 AM, 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
[ strip excellent expl
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 r
On Thu, Jul 17, 2014 at 6:01 AM, Michel Dänzer 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 write-combined GTT tur
On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer 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 these 3 patch
Tom Stellard 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 a/src/gallium/state_trackers/c
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 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
> ---
> src/gallium/state_trackers/clover/core/timestamp.cpp | 1 +
> 1 file changed, 1 insertion(+)
>
>
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 wrote
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 wrote:
> Hi,
>
> GPU: Radeon HD 5770
> mesa: 10.2.2 with gallium/llvm backend
> llvm: 3.4.2
> linux: 3.15.3
> xf86-video-ati:
On 17.07.2014 12:01, Michel Dänzer wrote:
> From: Michel Dänzer
>
> 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 reads from write-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 even
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
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
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
From: Michel Dänzer
Doesn't seem necessary, the GART table memory should be persistent.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/cik.c | 1 -
drivers/gpu/drm/radeon/evergreen.c | 1 -
drivers/gpu/drm/radeon/ni.c | 1 -
drivers/gpu/drm/radeon/r100.c|
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
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
b/src/gallium/drivers/radeon/r600_buffer_common.c
index c8a0723..6f7fa29 1
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
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 ++
drivers/gpu/drm/radeon/radeon_ring.c | 2 +-
5 files changed
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
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 | 4 ++--
drivers/gpu/drm/radeon/
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
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
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 4e6b897..40917f
From: Michel Dänzer
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
---
src/gallium/drivers/radeon/r600_buffer_common.c
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
Signed-off-by: Michel Dänzer
---
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 | 8
drivers/gpu/drm/radeon/radeon_ga
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
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 ++--
src/gallium/drivers/r300/r300_texture.c | 2 +-
src/
From: Michel Dänzer
Should reduce overhead because the caching buffer manager doesn't need to
consider buffers of the wrong type.
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 10 +++---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 16 +
88 matches
Mail list logo
