Re: rendering scene on a card different from the one displaying

2024-01-27 Thread Konstantin Kharlamov 
On Thu, 2024-01-25 at 18:13 +0300, test wrote:
> What is the most proper way to re-route output from a rendering card 
> (which can have it's output disconnected or don't have it at all) to
> a 
> displaying card (weak one, iGPU etc)?
> For example, a laptop with an external card in an ExpressCard riser
> (no 
> external display is connected to the card), or a desktop PC with 
> embedded video plus Nvidia Tesla?
> How should I configure Mesa in order to get «auto-screen-grabbing»
> from 
> the rendering card to the displaying one?

Fixed the title.

Sounds like you're interested in `DRI_PRIME` variable. See
documentation here
https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME

Assuming you want this for development purposes, you can also use
Vulkan API, but Idk details here.

This is a user question though, so belongs to mesa-users and not to
mesa-dev.

Re: Mesa >= 23.3.x and python 3.6 (was a typo 2.6) …

2024-01-21 Thread Konstantin Kharlamov 
On Fri, 2024-01-19 at 20:32 +0100, Stefan Dirsch wrote:
> On Fri, Jan 19, 2024 at 12:35:58PM -0500, Matt Turner wrote:
> > On Thu, Jan 18, 2024 at 10:22 AM Stefan Dirsch 
> > wrote:
> > > I noticed that with version 23.3.x Mesa no longer can be built
> > > with python
> > > 2.6. It still worked with Mesa 23.2.1.
> > 
> > For anyone who got this far and was completely incredulous... this
> > (and the subject) is typo'd -- the problem is about Python 3.6, not
> > 2.6.
> 
> I'm pretty sure you were the first and only one. :-( I've corrected
> it in the
> body by doing a reply to my own message, but how do I correct a typo
> in the
> subject ... I'll try to send the message again with also the correct
> subject. Then I'll be blamed for bringing up the same topic twice and
> spamming
> the list. Sigh.

Don't worry, just fix the title while replying. You can also add
something like "(was a typo 2.6)" as I just did in this email, so that
people who read by thread would be aware this isn't about python2 

Re: [Mesa-dev] Rust drivers in Mesa

2020-10-03 Thread Konstantin Kharlamov 
On Sun, 2020-10-04 at 00:48 +0300, Konstantin Kharlamov wrote: The standard
> > library is rather minimal "because just pull in 1000 crates".  The distro
> > people can correct me if I'm wrong, but when librsvg went to rust it was a
> > nightmare, several distros went a long time without updates because of 
> > cargo.
> 
> IIRC, the problem wit librsvg was because Clang 

Sorry, I mean LLVM of course.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

2020-10-03 Thread Konstantin Kharlamov 
On Fri, 2020-10-02 at 08:04 -0700, Dylan Baker wrote:

> And if you're not going to use cargo, is rust really a win?

Sure. When people talk about Rust in context of advantages against other
languages, I don't remember Cargo ever being mentioned. People love it for other
reasons.

> The standard library is rather minimal "because just pull in 1000 crates". The
> distro people can correct me if I'm wrong, but when librsvg went to rust it 
> was
> a nightmare, several distros went a long time without updates because of 
> cargo.

IIRC, the problem wit librsvg was because Clang didn't support some CPU
architectures on which librsvg was used. So people simply could not build it. I
don't remember hearing about any other issues.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

2020-10-03 Thread Konstantin Kharlamov 
On Sat, 2020-10-03 at 00:51 +0200, timur.kris...@gmail.com wrote:
> The Rust syntax is slightly annoying. They departed from C/C++ enough
> to make Rust look different, but then they got lazy and for some reason
> they chose to keep the most annoying parts from C/C++ like curly braces
> and semicolons, so even if we switch to Rust we can still enjoy
> debating important topics like where to put curly braces, how many
> spaces or tabs are best, and so on.

Unlike C++ though, Rust have reason for semicolons. In Rust you can write a
subexpression, whose result gets assigned to a variable, and you "return" this
result from the subexpression by omitting semicolon. In C++ you have to use a
lambda for that.

Talking of syntax, it may not be ideal, but since you compare it to C++, Rust
syntax is better. Off the top of my head:

1. No "const" modifiers, everything is immutable by default, which is how modern
   language should look like (because really, most of the things you work with 
in
   a function are either never modified (e.g. some arguments) or only upon
   creation — i.e. basically never too)
2. No braces in if-conditions. So you have one less pair of braces to eyeball
   while reading complex `if ((foo()+x) && (bar()) || buzz())` statements.
3. Lambda syntax is less to write and to read: less brackets/braces.
4. Way better syntax for Algebraic Data Types. E.g. in C++ you might have a
   `std::variant MyADT`, where all thee fields are ultimately
   anonymous, they only have type. In Rust on the other hand you have a `enum
   MyADT {Event1(Foo), Event2(bar), Event3(Buzz)}`, and you know what these 
types
   actually represent.
   
   I recall in modern C++ you can use `union`, but then you have to wrap it with
   something that tracks the field currently set; and I guess that alone shows 
it
   is more to write than in Rust.
   
These are just something I remember offhand, I'm sure there're more examples
regarding syntax.

> My main concern is that memory is just one of many resources that we
> need to use safely, but it's the only one that Rust concerns itself
> with. Memory safety can give you a false sense of security. It's
> possible to write insecure apps that are perfectly memory safe.

Well, this is a correct thought, but I don't see what point are you trying to
make here. I mean, you can write a bad program in any existing language,
sure. Rust gets rid of one possible problem, so… one problem less is good, I
guess?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: enable -fmerge-all-constants by default

2018-07-25 Thread Konstantin Kharlamov 
FWIW I just realized it also enables -fmerge-constants which is enabled 
at all optimize levels, and built/compared it with fmerge-all-constants. 
The difference is still noticeable. If anybody interested, I can 
pretty-format it, and send here.


On 25.07.2018 14:03, Konstantin Kharlamov wrote:

This is a standard non-conforming optimization, which, quoting,
"…considers e.g. even constant initialized arrays or initialized
constant variables with integral or floating-point types. Languages like
C or C++ require each variable, including multiple instances of the same
variable in recursive calls, to have distinct locations, so using this
option results in non-conforming behavior."

Having the same or distinct addresses of constants in recursive calls is
too obscure behavior to make any use of. More over, until 4 April 2018
clang have had this option enabled by default¹, and nobody ever noticed
until kernel build fail this year (having a low-level hackery in kernel
surprises no one), resulting in PR disabling the option by default.

As for Mesa: I personally have been using the option for release builds
since forever, never had any problems.

Real world significance, sizes of binaries in bytes:

default  | -fmerge-all-constants
| diff
-
  8048024 <-> bellagio/libomx_mesa.so |  7867800 <-> 
bellagio/libomx_mesa.so | -180224
10209120 <-> d3d/d3dadapter9.so.1.0.0| 10016608 <-> 
d3d/d3dadapter9.so.1.0.0| -192512
14464936 <-> dri/i915_dri.so | 14383016 <-> dri/i915_dri.so 
| -81920
16894344 <-> dri/kms_swrast_dri.so   | 16644488 <-> 
dri/kms_swrast_dri.so   | -249856
  8077560 <-> dri/nouveau_drv_video.so|  7893240 <-> 
dri/nouveau_drv_video.so| -184320
  3882872 <-> gallium-pipe/pipe_nouveau.so|  3870584 <-> 
gallium-pipe/pipe_nouveau.so| -12288
  2511160 <-> gallium-pipe/pipe_r300.so   |  2502968 <-> 
gallium-pipe/pipe_r300.so   | -8192
  2818520 <-> gallium-pipe/pipe_r600.so   |  2810328 <-> 
gallium-pipe/pipe_r600.so   | -8192
  4123056 <-> gallium-pipe/pipe_radeonsi.so   |  3955120 <-> 
gallium-pipe/pipe_radeonsi.so   | -167936
  2413936 <-> gallium-pipe/pipe_swrast.so |  2401648 <-> 
gallium-pipe/pipe_swrast.so | -12288
  2701360 <-> gallium-pipe/pipe_vmwgfx.so |  2689072 <-> 
gallium-pipe/pipe_vmwgfx.so | -12288
   582496 <-> libGLX_mesa.so.0.0.0|   578400 <-> 
libGLX_mesa.so.0.0.0| -4096
23451656 <-> libMesaOpenCL.so.1.0.0  | 23447560 <-> 
libMesaOpenCL.so.1.0.0  | -4096
10370344 <-> libOSMesa.so.8.0.0  | 10300712 <-> libOSMesa.so.8.0.0  
| -69632
  4766032 <-> libvulkan_intel.so  |  4745552 <-> libvulkan_intel.so 
 | -20480
  2761376 <-> libvulkan_radeon.so |  2753184 <-> 
libvulkan_radeon.so | -8192
  4703776 <-> libxatracker.so.2.4.0   |  4687392 <-> 
libxatracker.so.2.4.0   | -16384
  8510392 <-> vdpau/libvdpau_nouveau.so.1.0.0 |  8326072 <-> 
vdpau/libvdpau_nouveau.so.1.0.0 | -184320

For consistency it's enabled for both debug and release builds.

1: https://reviews.llvm.org/D45289

Signed-off-by: Konstantin Kharlamov 
---
  meson.build | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meson.build b/meson.build
index e05645cbf3..36016cf959 100644
--- a/meson.build
+++ b/meson.build
@@ -794,6 +794,11 @@ foreach a : ['-Wall', '-fno-math-errno', 
'-fno-trapping-math',
endif
  endforeach
  
+if ['gcc', 'clang'].contains(cc.get_id())

+  c_args += '-fmerge-all-constants'
+  cpp_args += '-fmerge-all-constants'
+endif
+
  # For some reason, the test for -Wno-foo always succeeds with gcc, even if the
  # option is not supported. Hence, check for -Wfoo instead.
  


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: enable -fmerge-all-constants by default

2018-07-25 Thread Konstantin Kharlamov 
This is a standard non-conforming optimization, which, quoting,
"…considers e.g. even constant initialized arrays or initialized
constant variables with integral or floating-point types. Languages like
C or C++ require each variable, including multiple instances of the same
variable in recursive calls, to have distinct locations, so using this
option results in non-conforming behavior."

Having the same or distinct addresses of constants in recursive calls is
too obscure behavior to make any use of. More over, until 4 April 2018
clang have had this option enabled by default¹, and nobody ever noticed
until kernel build fail this year (having a low-level hackery in kernel
surprises no one), resulting in PR disabling the option by default.

As for Mesa: I personally have been using the option for release builds
since forever, never had any problems.

Real world significance, sizes of binaries in bytes:

default  | -fmerge-all-constants
| diff
-
 8048024 <-> bellagio/libomx_mesa.so |  7867800 <-> 
bellagio/libomx_mesa.so | -180224
10209120 <-> d3d/d3dadapter9.so.1.0.0| 10016608 <-> 
d3d/d3dadapter9.so.1.0.0| -192512
14464936 <-> dri/i915_dri.so | 14383016 <-> dri/i915_dri.so 
| -81920
16894344 <-> dri/kms_swrast_dri.so   | 16644488 <-> 
dri/kms_swrast_dri.so   | -249856
 8077560 <-> dri/nouveau_drv_video.so|  7893240 <-> 
dri/nouveau_drv_video.so| -184320
 3882872 <-> gallium-pipe/pipe_nouveau.so|  3870584 <-> 
gallium-pipe/pipe_nouveau.so| -12288
 2511160 <-> gallium-pipe/pipe_r300.so   |  2502968 <-> 
gallium-pipe/pipe_r300.so   | -8192
 2818520 <-> gallium-pipe/pipe_r600.so   |  2810328 <-> 
gallium-pipe/pipe_r600.so   | -8192
 4123056 <-> gallium-pipe/pipe_radeonsi.so   |  3955120 <-> 
gallium-pipe/pipe_radeonsi.so   | -167936
 2413936 <-> gallium-pipe/pipe_swrast.so |  2401648 <-> 
gallium-pipe/pipe_swrast.so | -12288
 2701360 <-> gallium-pipe/pipe_vmwgfx.so |  2689072 <-> 
gallium-pipe/pipe_vmwgfx.so | -12288
  582496 <-> libGLX_mesa.so.0.0.0|   578400 <-> 
libGLX_mesa.so.0.0.0| -4096
23451656 <-> libMesaOpenCL.so.1.0.0  | 23447560 <-> 
libMesaOpenCL.so.1.0.0  | -4096
10370344 <-> libOSMesa.so.8.0.0  | 10300712 <-> libOSMesa.so.8.0.0  
| -69632
 4766032 <-> libvulkan_intel.so  |  4745552 <-> libvulkan_intel.so  
| -20480
 2761376 <-> libvulkan_radeon.so |  2753184 <-> libvulkan_radeon.so 
| -8192
 4703776 <-> libxatracker.so.2.4.0   |  4687392 <-> 
libxatracker.so.2.4.0   | -16384
 8510392 <-> vdpau/libvdpau_nouveau.so.1.0.0 |  8326072 <-> 
vdpau/libvdpau_nouveau.so.1.0.0 | -184320

For consistency it's enabled for both debug and release builds.

1: https://reviews.llvm.org/D45289

Signed-off-by: Konstantin Kharlamov 
---
 meson.build | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meson.build b/meson.build
index e05645cbf3..36016cf959 100644
--- a/meson.build
+++ b/meson.build
@@ -794,6 +794,11 @@ foreach a : ['-Wall', '-fno-math-errno', 
'-fno-trapping-math',
   endif
 endforeach
 
+if ['gcc', 'clang'].contains(cc.get_id())
+  c_args += '-fmerge-all-constants'
+  cpp_args += '-fmerge-all-constants'
+endif
+
 # For some reason, the test for -Wno-foo always succeeds with gcc, even if the
 # option is not supported. Hence, check for -Wfoo instead.
 
-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/6] r600g: some -Wsign-compare fixes

2018-06-04 Thread Konstantin Kharlamov 

On 03.06.2018 16:03, Gert Wollny wrote:

Patches 2-4 Reviewed-By: Gert Wollny 
I can't push them though

I'd like to add that for the future it would be better to

   - send the patches for st and r600 as separate series, this would
 make it easier to find reviewers
   - when fixing warning to add the specific warnings you fixed  to
 the commit messages (actually Ian Romanick gave me that hint)

Best,
Gert


Thank you for R-bs, and tips!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] r600g: fix unused variable warning

2018-06-04 Thread Konstantin Kharlamov 

On 03.06.2018 15:41, Gert Wollny wrote:

This patch doesn't apply, the "int i" was deleted already; I didn't
find the commit though.


Oh, well. Good thing somebody that cleaned it up already :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] r600: don't emit tes samplers/views when tes isn't active

2018-01-02 Thread Konstantin Kharlamov 

Yeah, the testing is done on AMD TURKS.

On 03.01.2018 10:29, Konstantin Kharlamov wrote:
Sorry, I don't have an expertise to give a r-b, but here's my t-b :) I 
found no statistically significant changes at "the big keybench" of 
`vblank_mode=0 ./xonotic-linux64-glx`.


But note, there's a trailing whitespace at patch 5 (first "+" after "@@ 
-1267,6 +1268,20 @@"), and patch 6 (first "+" after "@@ -1723,6 +1723,21 
@@").


Tested-by: Konstantin Kharlamov <hi-an...@yandex.ru>

On 03.01.2018 05:25, srol...@vmware.com wrote:

From: Roland Scheidegger <srol...@vmware.com>

Similar to const buffers. The driver must not emit any tes-related 
state if tes

is disabled, since the hw slots are all shared by VS, therefore it would
overwrite them (the mesa state tracker might not do this, but it would be
perfectly legal to do so).
Nevertheless I think the dirty state tracking logic in the driver is
fundamentally flawed when tes is disabled/enabled, since it looks to 
me like
the VS (and TES) state would not get reemitted to the correct slots 
(if it's

not dirty anyway). Unless I'm missing something...
Theoretically, the overwrite problem could be solved by using 
non-overlapping
resource slots for TES and VS (since we're not even close to using 
half the
resource slots), but it wouldn't work for constant buffers nor 
samplers, and
for VS would still need to propagate changes to both LS and VS, so 
probably

not a useful idea.
Unfortunately there's zero coverage of this with piglit, since all 
tessellation
shader tests are just shader_runner tests, which are unsuitable for 
testing
any kind of state dependency tracking issues (so I can't even quickly 
hack

something up to proove it and fix it...).
TCS otoh is just fine - like GS it has its own hw slots.
---
  src/gallium/drivers/r600/evergreen_state.c   |  4 
  src/gallium/drivers/r600/r600_state_common.c | 15 +++
  2 files changed, 19 insertions(+)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c

index 4cc48dfa11..fb1de9cbf4 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2334,6 +2334,8 @@ static void 
evergreen_emit_tcs_sampler_views(struct r600_context *rctx, struct r
  static void evergreen_emit_tes_sampler_views(struct r600_context 
*rctx, struct r600_atom *atom)

  {
+    if (!rctx->tes_shader)
+    return;
  evergreen_emit_sampler_views(rctx, 
>samplers[PIPE_SHADER_TESS_EVAL].views,
   EG_FETCH_CONSTANTS_OFFSET_VS + 
R600_MAX_CONST_BUFFERS, 0);

  }
@@ -2404,6 +2406,8 @@ static void 
evergreen_emit_tcs_sampler_states(struct r600_context *rctx, struct
  static void evergreen_emit_tes_sampler_states(struct r600_context 
*rctx, struct r600_atom *atom)

  {
+    if (!rctx->tes_shader)
+    return;
  evergreen_emit_sampler_states(rctx, 
>samplers[PIPE_SHADER_TESS_EVAL], 18,

    R_00A414_TD_VS_SAMPLER0_BORDER_INDEX, 0);
  }
diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c

index 4364350487..a434156c16 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1723,6 +1723,21 @@ static bool r600_update_derived_state(struct 
r600_context *rctx)

  UPDATE_SHADER_CLIP(R600_HW_STAGE_VS, vs);
  }
  }
+
+    /*
+ * XXX: I believe there's some fatal flaw in the dirty state 
logic when

+ * enabling/disabling tes.
+ * VS/ES share all buffer/resource/sampler slots. If TES is enabled,
+ * it will therefore overwrite the VS slots. If it now gets 
disabled,
+ * the VS needs to rebind all buffer/resource/sampler slots - not 
only

+ * has TES overwritten the corresponding slots, but when the VS was
+ * operating as LS the things with correpsonding dirty bits got 
bound
+ * to LS slots and won't reflect what is dirty as VS stage even 
if the

+ * TES didn't overwrite it. The story for re-enabled TES is similar.
+ * In any case, we're not allowed to submit any TES state when
+ * TES is disabled (the state tracker may not do this but this looks
+ * like an optimization to me, not something which can be relied 
on).

+ */
  /* Update clip misc state. */
  if (clip_so_current) {


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] r600: don't emit tes samplers/views when tes isn't active

2018-01-02 Thread Konstantin Kharlamov 
Sorry, I don't have an expertise to give a r-b, but here's my t-b :) I 
found no statistically significant changes at "the big keybench" of 
`vblank_mode=0 ./xonotic-linux64-glx`.


But note, there's a trailing whitespace at patch 5 (first "+" after "@@ 
-1267,6 +1268,20 @@"), and patch 6 (first "+" after "@@ -1723,6 +1723,21 
@@").


Tested-by: Konstantin Kharlamov <hi-an...@yandex.ru>

On 03.01.2018 05:25, srol...@vmware.com wrote:

From: Roland Scheidegger <srol...@vmware.com>

Similar to const buffers. The driver must not emit any tes-related state if tes
is disabled, since the hw slots are all shared by VS, therefore it would
overwrite them (the mesa state tracker might not do this, but it would be
perfectly legal to do so).
Nevertheless I think the dirty state tracking logic in the driver is
fundamentally flawed when tes is disabled/enabled, since it looks to me like
the VS (and TES) state would not get reemitted to the correct slots (if it's
not dirty anyway). Unless I'm missing something...
Theoretically, the overwrite problem could be solved by using non-overlapping
resource slots for TES and VS (since we're not even close to using half the
resource slots), but it wouldn't work for constant buffers nor samplers, and
for VS would still need to propagate changes to both LS and VS, so probably
not a useful idea.
Unfortunately there's zero coverage of this with piglit, since all tessellation
shader tests are just shader_runner tests, which are unsuitable for testing
any kind of state dependency tracking issues (so I can't even quickly hack
something up to proove it and fix it...).
TCS otoh is just fine - like GS it has its own hw slots.
---
  src/gallium/drivers/r600/evergreen_state.c   |  4 
  src/gallium/drivers/r600/r600_state_common.c | 15 +++
  2 files changed, 19 insertions(+)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 4cc48dfa11..fb1de9cbf4 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2334,6 +2334,8 @@ static void evergreen_emit_tcs_sampler_views(struct 
r600_context *rctx, struct r
  
  static void evergreen_emit_tes_sampler_views(struct r600_context *rctx, struct r600_atom *atom)

  {
+   if (!rctx->tes_shader)
+   return;
evergreen_emit_sampler_views(rctx, 
>samplers[PIPE_SHADER_TESS_EVAL].views,
 EG_FETCH_CONSTANTS_OFFSET_VS + 
R600_MAX_CONST_BUFFERS, 0);
  }
@@ -2404,6 +2406,8 @@ static void evergreen_emit_tcs_sampler_states(struct 
r600_context *rctx, struct
  
  static void evergreen_emit_tes_sampler_states(struct r600_context *rctx, struct r600_atom *atom)

  {
+   if (!rctx->tes_shader)
+   return;
evergreen_emit_sampler_states(rctx, 
>samplers[PIPE_SHADER_TESS_EVAL], 18,
  R_00A414_TD_VS_SAMPLER0_BORDER_INDEX, 0);
  }
diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index 4364350487..a434156c16 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -1723,6 +1723,21 @@ static bool r600_update_derived_state(struct 
r600_context *rctx)
UPDATE_SHADER_CLIP(R600_HW_STAGE_VS, vs);
}
}
+   
+   /*
+* XXX: I believe there's some fatal flaw in the dirty state logic when
+* enabling/disabling tes.
+* VS/ES share all buffer/resource/sampler slots. If TES is enabled,
+* it will therefore overwrite the VS slots. If it now gets disabled,
+* the VS needs to rebind all buffer/resource/sampler slots - not only
+* has TES overwritten the corresponding slots, but when the VS was
+* operating as LS the things with correpsonding dirty bits got bound
+* to LS slots and won't reflect what is dirty as VS stage even if the
+* TES didn't overwrite it. The story for re-enabled TES is similar.
+* In any case, we're not allowed to submit any TES state when
+* TES is disabled (the state tracker may not do this but this looks
+* like an optimization to me, not something which can be relied on).
+*/
  
  	/* Update clip misc state. */

if (clip_so_current) {


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/6 v3] r600g: do not use "fast-clear" for small textures (v3)

2017-12-31 Thread Konstantin Kharlamov 
Ported from radeonsi. Improves windowed glxgears ran as

vblank_mode=0 glxgears -info -geometry 0+0+512+512

from ≈2270 FPS to ≈2360 FPS. Tested with AMD TURKS.

v2: turned out glxgears ignores the option above, the correct way would
be "512x512+0+0". Now it can be seen 512x512 actually loses 30 FPS.
300×300 however wins around a hundred FPS, and to leave some room in
case results may differ for other cards I want not to nitpick in search
of an optimum but to simply leave 300×300 in the code.
v3: remove redundant braces, and try harder for the mail to stick to
the rest of the series.

Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/drivers/r600/r600_texture.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_texture.c 
b/src/gallium/drivers/r600/r600_texture.c
index 03cdcd22ee..778e801136 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -1793,6 +1793,16 @@ void evergreen_do_fast_color_clear(struct 
r600_common_context *rctx,
!(tex->resource.external_usage & 
PIPE_HANDLE_USAGE_EXPLICIT_FLUSH))
continue;
 
+   /* Use a slow clear for small surfaces where the cost of
+* the eliminate pass can be higher than the benefit of fast
+* clear. AMDGPU-pro does this, but the numbers may differ.
+*
+* This helps on both dGPUs and APUs, even small ones.
+*/
+   if (tex->resource.b.b.nr_samples <= 1 &&
+   tex->resource.b.b.width0 * tex->resource.b.b.height0 <= 300 
* 300)
+   continue;
+
{
/* 128-bit formats are unusupported */
if (tex->surface.bpe > 8) {
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] r600g: do not use "fast-clear" for small textures

2017-12-31 Thread Konstantin Kharlamov 
Ok, you know what, it really annoys me that α) I forgot redundant 
braces, and β) this mail didn't stuck to the rest of the series. Let me 
try a v3 just because of that.


On 31.12.2017 22:33, Konstantin Kharlamov wrote:

Ported from radeonsi. Improves windowed glxgears ran as

vblank_mode=0 glxgears -info -geometry 0+0+512+512

from ≈2270 FPS to ≈2360 FPS. Tested with AMD TURKS.

v2: turned out glxgears ignores the option above, the correct way would
be "512x512+0+0". Now it can be seen 512x512 actually loses 30 FPS.
300×300 however wins around a hundred FPS, and to leave some room in
case results may differ for other cards I want not to nitpick in search
of an optimum but to simply leave 300×300 in the code.

Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
  src/gallium/drivers/r600/r600_texture.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_texture.c 
b/src/gallium/drivers/r600/r600_texture.c
index 03cdcd22ee..638c601e5e 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -1793,6 +1793,17 @@ void evergreen_do_fast_color_clear(struct 
r600_common_context *rctx,
!(tex->resource.external_usage & 
PIPE_HANDLE_USAGE_EXPLICIT_FLUSH))
continue;
  
+		/* Use a slow clear for small surfaces where the cost of

+* the eliminate pass can be higher than the benefit of fast
+* clear. AMDGPU-pro does this, but the numbers may differ.
+*
+* This helps on both dGPUs and APUs, even small ones.
+*/
+   if (tex->resource.b.b.nr_samples <= 1 &&
+   tex->resource.b.b.width0 * tex->resource.b.b.height0 <= 300 
* 300) {
+   continue;
+   }
+
{
/* 128-bit formats are unusupported */
if (tex->surface.bpe > 8) {


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] r600g: do not use "fast-clear" for small textures

2017-12-31 Thread Konstantin Kharlamov 
Ported from radeonsi. Improves windowed glxgears ran as

vblank_mode=0 glxgears -info -geometry 0+0+512+512

from ≈2270 FPS to ≈2360 FPS. Tested with AMD TURKS.

v2: turned out glxgears ignores the option above, the correct way would
be "512x512+0+0". Now it can be seen 512x512 actually loses 30 FPS.
300×300 however wins around a hundred FPS, and to leave some room in
case results may differ for other cards I want not to nitpick in search
of an optimum but to simply leave 300×300 in the code.

Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/drivers/r600/r600_texture.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_texture.c 
b/src/gallium/drivers/r600/r600_texture.c
index 03cdcd22ee..638c601e5e 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -1793,6 +1793,17 @@ void evergreen_do_fast_color_clear(struct 
r600_common_context *rctx,
!(tex->resource.external_usage & 
PIPE_HANDLE_USAGE_EXPLICIT_FLUSH))
continue;
 
+   /* Use a slow clear for small surfaces where the cost of
+* the eliminate pass can be higher than the benefit of fast
+* clear. AMDGPU-pro does this, but the numbers may differ.
+*
+* This helps on both dGPUs and APUs, even small ones.
+*/
+   if (tex->resource.b.b.nr_samples <= 1 &&
+   tex->resource.b.b.width0 * tex->resource.b.b.height0 <= 300 
* 300) {
+   continue;
+   }
+
{
/* 128-bit formats are unusupported */
if (tex->surface.bpe > 8) {
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] r600g/state_trackers small cleanups

2017-12-28 Thread Konstantin Kharlamov 
I forgot to tell: there's actually lots of warnings for Wsign-compare, so if 
anybody wanted, it's something to look at. I fixed only as much of the code as 
I had a mood for :Ь

В письме от пятница, 29 декабря 2017 г. 8:32:26 MSK пользователь Konstantin 
Kharlamov написал:
> Mostly a quick run with -Wsign-compare. I didn't see any real problems
> though except for the changes at r600_isa.c where a unsigned been
> compared with -1.
> 
> No changes in piglit except for two unstable tests for me: dlist and
> multiple-texture-reading.
> 
> Regarding how did I manage to run piglit given it hangs r600g: well, it
> hangs in the very end on the same test, and really saves the results. So
> even though piglit run requires me to reboot in the end, it still gives
> most of results, except for, maybe, some dozens in the end.
> 
> P.S. I don't have commit rights.
> 
> Konstantin Kharlamov (6):
>   r600g: do not use "fast-clear" for small textures
>   r600g: constify some variables
>   nine: constify some variables
>   st/glx: constify some variables
>   r600g: some -Wsign-compare fixes
>   r600g: fix unused variable warning
> 
>  src/gallium/drivers/r600/cayman_msaa.c|  2 +-
>  src/gallium/drivers/r600/eg_debug.c   |  6 +++---
>  src/gallium/drivers/r600/evergreen_state.c|  8 
>  src/gallium/drivers/r600/r600_isa.c   |  6 +++---
>  src/gallium/drivers/r600/r600_pipe.h  |  2 +-
>  src/gallium/drivers/r600/r600_query.c |  2 +-
>  src/gallium/drivers/r600/r600_state.c | 12 ++--
>  src/gallium/drivers/r600/r600_state_common.c  |  6 ++
>  src/gallium/drivers/r600/r600_test_dma.c  |  2 +-
>  src/gallium/drivers/r600/r600_texture.c   | 10 ++
>  src/gallium/drivers/r600/sb/sb_expr.cpp   |  2 +-
>  src/gallium/state_trackers/glx/xlib/glx_getproc.c |  2 +-
>  src/gallium/state_trackers/nine/nine_pipe.h   |  2 +-
>  src/gallium/state_trackers/nine/nine_shader.c | 10 +-
>  14 files changed, 40 insertions(+), 32 deletions(-)
> 
> 




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/6] r600g: do not use "fast-clear" for small textures

2017-12-28 Thread Konstantin Kharlamov 
Ported from radeonsi. Improves windowed glxgears ran as

vblank_mode=0 glxgears -info -geometry 0+0+512+512

from ≈2270 FPS to ≈2360 FPS. Tested with AMD TURKS.

Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/drivers/r600/r600_texture.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/r600/r600_texture.c 
b/src/gallium/drivers/r600/r600_texture.c
index 03cdcd22ee..6739553f94 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -1793,6 +1793,16 @@ void evergreen_do_fast_color_clear(struct 
r600_common_context *rctx,
!(tex->resource.external_usage & 
PIPE_HANDLE_USAGE_EXPLICIT_FLUSH))
continue;
 
+   /* Use a slow clear for small surfaces where the cost of
+* the eliminate pass can be higher than the benefit of fast
+* clear. AMDGPU-pro does this, but the numbers may differ.
+*
+* This helps on both dGPUs and APUs, even small ones.
+*/
+   if (tex->resource.b.b.nr_samples <= 1 &&
+   tex->resource.b.b.width0 * tex->resource.b.b.height0 <= 512 
* 512)
+   continue;
+
{
/* 128-bit formats are unusupported */
if (tex->surface.bpe > 8) {
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 6/6] r600g: fix unused variable warning

2017-12-28 Thread Konstantin Kharlamov 
Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/drivers/r600/r600_state_common.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index ec8945f084..dc5cc0ad2e 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -902,7 +902,6 @@ struct r600_pipe_shader_selector 
*r600_create_shader_state_tokens(struct pipe_co
  unsigned 
pipe_shader_type)
 {
struct r600_pipe_shader_selector *sel = 
CALLOC_STRUCT(r600_pipe_shader_selector);
-   int i;
 
sel->type = pipe_shader_type;
sel->tokens = tgsi_dup_tokens(tokens);
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/6] r600g: constify some variables

2017-12-28 Thread Konstantin Kharlamov 
Just a nice hint for both peoples and compilers.

Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/drivers/r600/cayman_msaa.c |  2 +-
 src/gallium/drivers/r600/evergreen_state.c |  2 +-
 src/gallium/drivers/r600/r600_query.c  |  2 +-
 src/gallium/drivers/r600/r600_state.c  | 12 ++--
 src/gallium/drivers/r600/sb/sb_expr.cpp|  2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/r600/cayman_msaa.c 
b/src/gallium/drivers/r600/cayman_msaa.c
index 6bc307a4bc..c1294536d3 100644
--- a/src/gallium/drivers/r600/cayman_msaa.c
+++ b/src/gallium/drivers/r600/cayman_msaa.c
@@ -219,7 +219,7 @@ void cayman_emit_msaa_config(struct radeon_winsys_cs *cs, 
int nr_samples,
 
if (setup_samples > 1) {
/* indexed by log2(nr_samples) */
-   unsigned max_dist[] = {
+   const unsigned max_dist[] = {
0,
eg_max_dist_2x,
eg_max_dist_4x,
diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index 0da665f634..ecb9c598e3 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1584,7 +1584,7 @@ static void evergreen_set_min_samples(struct pipe_context 
*ctx, unsigned min_sam
 }
 
 /* 8xMSAA */
-static uint32_t sample_locs_8x[] = {
+static const uint32_t sample_locs_8x[] = {
FILL_SREG(-1,  1,  1,  5,  3, -5,  5,  3),
FILL_SREG(-7, -1, -3, -7,  7, -3, -5,  7),
FILL_SREG(-1,  1,  1,  5,  3, -5,  5,  3),
diff --git a/src/gallium/drivers/r600/r600_query.c 
b/src/gallium/drivers/r600/r600_query.c
index 987da9a806..8194d6e7c7 100644
--- a/src/gallium/drivers/r600/r600_query.c
+++ b/src/gallium/drivers/r600/r600_query.c
@@ -1914,7 +1914,7 @@ void r600_query_fix_enabled_rb_mask(struct 
r600_common_screen *rscreen)
 #define XG(group_, name_, query_type_, type_, result_type_) \
XFULL(name_, query_type_, type_, result_type_, 
R600_QUERY_GROUP_##group_)
 
-static struct pipe_driver_query_info r600_driver_query_list[] = {
+static const struct pipe_driver_query_info r600_driver_query_list[] = {
X("num-compilations",   NUM_COMPILATIONS,   UINT64, 
CUMULATIVE),
X("num-shaders-created",NUM_SHADERS_CREATED,UINT64, 
CUMULATIVE),
X("num-shader-cache-hits",  NUM_SHADER_CACHE_HITS,  UINT64, 
CUMULATIVE),
diff --git a/src/gallium/drivers/r600/r600_state.c 
b/src/gallium/drivers/r600/r600_state.c
index cbf860f45f..52adebe6cf 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/drivers/r600/r600_state.c
@@ -1220,22 +1220,22 @@ static void r600_set_framebuffer_state(struct 
pipe_context *ctx,
rctx->framebuffer.do_update_surf_dirtiness = true;
 }
 
-static uint32_t sample_locs_2x[] = {
+static const uint32_t sample_locs_2x[] = {
FILL_SREG(-4, 4, 4, -4, -4, 4, 4, -4),
FILL_SREG(-4, 4, 4, -4, -4, 4, 4, -4),
 };
-static unsigned max_dist_2x = 4;
+static const unsigned max_dist_2x = 4;
 
-static uint32_t sample_locs_4x[] = {
+static const uint32_t sample_locs_4x[] = {
FILL_SREG(-2, -2, 2, 2, -6, 6, 6, -6),
FILL_SREG(-2, -2, 2, 2, -6, 6, 6, -6),
 };
-static unsigned max_dist_4x = 6;
-static uint32_t sample_locs_8x[] = {
+static const unsigned max_dist_4x = 6;
+static const uint32_t sample_locs_8x[] = {
FILL_SREG(-1,  1,  1,  5,  3, -5,  5,  3),
FILL_SREG(-7, -1, -3, -7,  7, -3, -5,  7),
 };
-static unsigned max_dist_8x = 7;
+static const unsigned max_dist_8x = 7;
 
 static void r600_get_sample_position(struct pipe_context *ctx,
 unsigned sample_count,
diff --git a/src/gallium/drivers/r600/sb/sb_expr.cpp 
b/src/gallium/drivers/r600/sb/sb_expr.cpp
index 7a5d62c8e8..7ad48e8ad3 100644
--- a/src/gallium/drivers/r600/sb/sb_expr.cpp
+++ b/src/gallium/drivers/r600/sb/sb_expr.cpp
@@ -330,7 +330,7 @@ void expr_handler::apply_alu_src_mod(const bc_alu , 
unsigned src,
 }
 
 void expr_handler::apply_alu_dst_mod(const bc_alu , literal ) {
-   float omod_coeff[] = {2.0f, 4.0, 0.5f};
+   const float omod_coeff[] = {2.0f, 4.0, 0.5f};
 
if (bc.omod)
v = v.f * omod_coeff[bc.omod - 1];
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/6] r600g: some -Wsign-compare fixes

2017-12-28 Thread Konstantin Kharlamov 
Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/drivers/r600/eg_debug.c  | 6 +++---
 src/gallium/drivers/r600/evergreen_state.c   | 6 +++---
 src/gallium/drivers/r600/r600_isa.c  | 6 +++---
 src/gallium/drivers/r600/r600_pipe.h | 2 +-
 src/gallium/drivers/r600/r600_state_common.c | 5 ++---
 src/gallium/drivers/r600/r600_test_dma.c | 2 +-
 6 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/src/gallium/drivers/r600/eg_debug.c 
b/src/gallium/drivers/r600/eg_debug.c
index ceb7c1672c..56195df296 100644
--- a/src/gallium/drivers/r600/eg_debug.c
+++ b/src/gallium/drivers/r600/eg_debug.c
@@ -78,7 +78,7 @@ static void print_named_value(FILE *file, const char *name, 
uint32_t value,
 static void eg_dump_reg(FILE *file, unsigned offset, uint32_t value,
uint32_t field_mask)
 {
-   int r, f;
+   unsigned r, f;
 
for (r = 0; r < ARRAY_SIZE(egd_reg_table); r++) {
const struct eg_reg *reg = _reg_table[r];
@@ -134,7 +134,7 @@ static void ac_parse_set_reg_packet(FILE *f, uint32_t *ib, 
unsigned count,
unsigned reg_offset)
 {
unsigned reg = (ib[1] << 2) + reg_offset;
-   int i;
+   unsigned i;
 
for (i = 0; i < count; i++)
eg_dump_reg(f, reg + i*4, ib[2+i], ~0);
@@ -149,7 +149,7 @@ static uint32_t *ac_parse_packet3(FILE *f, uint32_t *ib, 
int *num_dw,
unsigned op = PKT3_IT_OPCODE_G(ib[0]);
const char *predicate = PKT3_PREDICATE(ib[0]) ? "(predicate)" : "";
const char *compute_mode = (ib[0] & 0x2) ? "(C)" : "";
-   int i;
+   unsigned i;
 
/* Print the name first. */
for (i = 0; i < ARRAY_SIZE(packet3_table); i++)
diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index ecb9c598e3..1aae9097f3 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -3915,7 +3915,7 @@ static void evergreen_set_hw_atomic_buffers(struct 
pipe_context *ctx,
 {
struct r600_context *rctx = (struct r600_context *)ctx;
struct r600_atomic_buffer_state *astate;
-   int i, idx;
+   unsigned i, idx;
 
astate = >atomic_buffer_state;
 
@@ -3951,7 +3951,7 @@ static void evergreen_set_shader_buffers(struct 
pipe_context *ctx,
struct r600_tex_color_info color;
struct eg_buf_res_params buf_params;
struct r600_resource *resource;
-   int i, idx;
+   unsigned i, idx;
unsigned old_mask;
 
if (shader != PIPE_SHADER_FRAGMENT &&
@@ -4042,7 +4042,7 @@ static void evergreen_set_shader_images(struct 
pipe_context *ctx,
const struct pipe_image_view *images)
 {
struct r600_context *rctx = (struct r600_context *)ctx;
-   int i;
+   unsigned i;
struct r600_image_view *rview;
struct pipe_resource *image;
struct r600_resource *resource;
diff --git a/src/gallium/drivers/r600/r600_isa.c 
b/src/gallium/drivers/r600/r600_isa.c
index 2633cdcdb9..0d3e93d141 100644
--- a/src/gallium/drivers/r600/r600_isa.c
+++ b/src/gallium/drivers/r600/r600_isa.c
@@ -557,7 +557,7 @@ int r600_isa_init(struct r600_context *ctx, struct r600_isa 
*isa) {
 
for (i = 0; i < ARRAY_SIZE(r600_alu_op_table); ++i) {
const struct alu_op_info *op = _alu_op_table[i];
-   unsigned opc;
+   int opc;
if (op->flags & AF_LDS || op->slots[isa->hw_class] == 0)
continue;
opc = op->opcode[isa->hw_class >> 1];
@@ -570,7 +570,7 @@ int r600_isa_init(struct r600_context *ctx, struct r600_isa 
*isa) {
 
for (i = 0; i < ARRAY_SIZE(fetch_op_table); ++i) {
const struct fetch_op_info *op = _op_table[i];
-   unsigned opc = op->opcode[isa->hw_class];
+   int opc = op->opcode[isa->hw_class];
if ((op->flags & FF_GDS) || ((opc & 0xFF) != opc))
continue; /* ignore GDS ops and INST_MOD versions for 
now */
isa->fetch_map[opc] = i + 1;
@@ -578,7 +578,7 @@ int r600_isa_init(struct r600_context *ctx, struct r600_isa 
*isa) {
 
for (i = 0; i < ARRAY_SIZE(cf_op_table); ++i) {
const struct cf_op_info *op = _op_table[i];
-   unsigned opc = op->opcode[isa->hw_class];
+   int opc = op->opcode[isa->hw_class];
if (opc == -1)
continue;
/* using offset for CF_ALU_xxx opcodes because they overlap 
with other
diff --git a/src/gallium/drivers/r600/r600_pipe.h 
b/src/gallium/drivers/r600/r600_pipe.h
index e042edf2b4..65206b023d 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gall

[Mesa-dev] [PATCH 0/6] r600g/state_trackers small cleanups

2017-12-28 Thread Konstantin Kharlamov 
Mostly a quick run with -Wsign-compare. I didn't see any real problems
though except for the changes at r600_isa.c where a unsigned been
compared with -1.

No changes in piglit except for two unstable tests for me: dlist and
multiple-texture-reading.

Regarding how did I manage to run piglit given it hangs r600g: well, it
hangs in the very end on the same test, and really saves the results. So
even though piglit run requires me to reboot in the end, it still gives
most of results, except for, maybe, some dozens in the end.

P.S. I don't have commit rights.

Konstantin Kharlamov (6):
  r600g: do not use "fast-clear" for small textures
  r600g: constify some variables
  nine: constify some variables
  st/glx: constify some variables
  r600g: some -Wsign-compare fixes
  r600g: fix unused variable warning

 src/gallium/drivers/r600/cayman_msaa.c|  2 +-
 src/gallium/drivers/r600/eg_debug.c   |  6 +++---
 src/gallium/drivers/r600/evergreen_state.c|  8 
 src/gallium/drivers/r600/r600_isa.c   |  6 +++---
 src/gallium/drivers/r600/r600_pipe.h  |  2 +-
 src/gallium/drivers/r600/r600_query.c |  2 +-
 src/gallium/drivers/r600/r600_state.c | 12 ++--
 src/gallium/drivers/r600/r600_state_common.c  |  6 ++
 src/gallium/drivers/r600/r600_test_dma.c  |  2 +-
 src/gallium/drivers/r600/r600_texture.c   | 10 ++
 src/gallium/drivers/r600/sb/sb_expr.cpp   |  2 +-
 src/gallium/state_trackers/glx/xlib/glx_getproc.c |  2 +-
 src/gallium/state_trackers/nine/nine_pipe.h   |  2 +-
 src/gallium/state_trackers/nine/nine_shader.c | 10 +-
 14 files changed, 40 insertions(+), 32 deletions(-)

-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/6] st/glx: constify some variables

2017-12-28 Thread Konstantin Kharlamov 
Just a nice hint for both peoples and compilers.

Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/state_trackers/glx/xlib/glx_getproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/glx/xlib/glx_getproc.c 
b/src/gallium/state_trackers/glx/xlib/glx_getproc.c
index e7564ad9cd..b0f04ceebc 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_getproc.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_getproc.c
@@ -43,7 +43,7 @@ struct name_address_pair {
 };
 
 
-static struct name_address_pair GLX_functions[] = {
+static const struct name_address_pair GLX_functions[] = {
/*** GLX_VERSION_1_0 ***/
{ "glXChooseVisual", (__GLXextFuncPtr) glXChooseVisual },
{ "glXCopyContext", (__GLXextFuncPtr) glXCopyContext },
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/6] st/nine: constify some variables

2017-12-28 Thread Konstantin Kharlamov 
Just a nice hint for both peoples and compilers.

Signed-off-by: Konstantin Kharlamov <hi-an...@yandex.ru>
---
 src/gallium/state_trackers/nine/nine_pipe.h   |  2 +-
 src/gallium/state_trackers/nine/nine_shader.c | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/nine/nine_pipe.h 
b/src/gallium/state_trackers/nine/nine_pipe.h
index 6bd4a0c897..c8fef62827 100644
--- a/src/gallium/state_trackers/nine/nine_pipe.h
+++ b/src/gallium/state_trackers/nine/nine_pipe.h
@@ -201,7 +201,7 @@ compressed_format( D3DFORMAT fmt )
 static inline boolean
 depth_stencil_format( D3DFORMAT fmt )
 {
-static D3DFORMAT allowed[] = {
+static const D3DFORMAT allowed[] = {
 D3DFMT_D16_LOCKABLE,
 D3DFMT_D32,
 D3DFMT_D15S1,
diff --git a/src/gallium/state_trackers/nine/nine_shader.c 
b/src/gallium/state_trackers/nine/nine_shader.c
index cc667ebfbc..42f0566083 100644
--- a/src/gallium/state_trackers/nine/nine_shader.c
+++ b/src/gallium/state_trackers/nine/nine_shader.c
@@ -378,7 +378,7 @@ struct sm1_instruction
 struct sm1_src_param dst_rel[1];
 struct sm1_dst_param dst[1];
 
-struct sm1_op_info *info;
+const struct sm1_op_info *info;
 };
 
 static void
@@ -2901,7 +2901,7 @@ DECL_SPECIAL(COMMENT)
 #define _OPI(o,t,vv1,vv2,pv1,pv2,d,s,h) \
 { D3DSIO_##o, TGSI_OPCODE_##t, { vv1, vv2 }, { pv1, pv2, }, d, s, h }
 
-struct sm1_op_info inst_table[] =
+static const struct sm1_op_info inst_table[] =
 {
 _OPI(NOP, NOP, V(0,0), V(3,0), V(0,0), V(3,0), 0, 0, SPECIAL(NOP)), /* 0 */
 _OPI(MOV, MOV, V(0,0), V(3,0), V(0,0), V(3,0), 1, 1, NULL),
@@ -3008,10 +3008,10 @@ struct sm1_op_info inst_table[] =
 _OPI(BREAKP, BRK,  V(0,0), V(3,0), V(2,1), V(3,0), 0, 1, SPECIAL(BREAKP))
 };
 
-struct sm1_op_info inst_phase =
+static const struct sm1_op_info inst_phase =
 _OPI(PHASE, NOP, V(0,0), V(0,0), V(1,4), V(1,4), 0, 0, SPECIAL(PHASE));
 
-struct sm1_op_info inst_comment =
+static const struct sm1_op_info inst_comment =
 _OPI(COMMENT, NOP, V(0,0), V(3,0), V(0,0), V(3,0), 0, 0, SPECIAL(COMMENT));
 
 static void
@@ -3279,7 +3279,7 @@ sm1_parse_instruction(struct shader_translator *tx)
 struct sm1_instruction *insn = >insn;
 HRESULT hr;
 DWORD tok;
-struct sm1_op_info *info = NULL;
+const struct sm1_op_info *info = NULL;
 unsigned i;
 
 sm1_parse_comments(tx, TRUE);
-- 
2.15.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: don't use fast color clear for small images even on APUs

2017-12-28 Thread Konstantin Kharlamov 
I'm wondering, how is r600g different in that regard? I tried wiring up the 
code into evergreen_do_fast_color_clear(), both in this state and by using 
256*256 — however FPS for me always varies around the same 1420.

That said, I'm seeing lots of CPU used by Xorg, glxgears, and compton — I'm 
wondering if CPU cap could be the reason?

В письме от среда, 13 декабря 2017 г. 2:53:12 MSK пользователь Marek Olšák 
написал:
> From: Marek Olšák 
> 
> Increase the limit and handle non-square images better.
> 
> This makes glxgears 20% faster on APUs, and a little more on dGPUs.
> We all use and love glxgears.
> ---
>  src/gallium/drivers/radeonsi/si_clear.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_clear.c 
> b/src/gallium/drivers/radeonsi/si_clear.c
> index 0ac83f4..464b9d7 100644
> --- a/src/gallium/drivers/radeonsi/si_clear.c
> +++ b/src/gallium/drivers/radeonsi/si_clear.c
> @@ -418,26 +418,25 @@ static void si_do_fast_color_clear(struct si_context 
> *sctx,
>   sctx->b.family == CHIP_STONEY)
>   tex->num_slow_clears++;
>   }
>  
>   bool need_decompress_pass = false;
>  
>   /* Use a slow clear for small surfaces where the cost of
>* the eliminate pass can be higher than the benefit of fast
>* clear. The closed driver does this, but the numbers may 
> differ.
>*
> -  * Always use fast clear on APUs.
> +  * This helps on both dGPUs and APUs, even small APUs like 
> Mullins.
>*/
> - bool too_small = sctx->screen->info.has_dedicated_vram &&
> -  tex->resource.b.b.nr_samples <= 1 &&
> -  tex->resource.b.b.width0 <= 256 &&
> -  tex->resource.b.b.height0 <= 256;
> + bool too_small = tex->resource.b.b.nr_samples <= 1 &&
> +  tex->resource.b.b.width0 *
> +  tex->resource.b.b.height0 <= 512 * 512;
>  
>   /* Try to clear DCC first, otherwise try CMASK. */
>   if (vi_dcc_enabled(tex, 0)) {
>   uint32_t reset_value;
>   bool clear_words_needed;
>  
>   if (sctx->screen->debug_flags & DBG(NO_DCC_CLEAR))
>   continue;
>  
>   /* This can only occur with MSAA. */
> 




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev