Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

2018-09-14 Thread Nicholas Miell 
On 09/12/2018 05:40 PM, Marek Olšák wrote:
> +static void
> +util_set_full_cpu_affinity(void)
> +{
> +   cpu_set_t cpuset;
> +
> +   CPU_ZERO();
> +   for (unsigned i = 0; i < CPU_SETSIZE; i++)
> +  CPU_SET(i, );
> +
> +   pthread_setaffinity_np(pthread_self(), sizeof(cpuset), );
> +}
>  
>  static void
> -util_init_cache_number(void)
> +util_init_thread_pinning(void)
>  {
> /* Get a semi-random number. */
> int64_t t = os_time_get_nano();
> L3_cache_number = (t ^ (t >> 8) ^ (t >> 16));
> +
> +   /* Reset thread affinity for all children of fork and exec to prevent
> +* spawned processes and threads from inheriting the current thread's
> +* affinity.
> +*
> +* What happens if a driver is unloaded and the app creates a thread?
> +*/
> +   pthread_atfork(NULL, NULL, util_set_full_cpu_affinity);
>  }
>  

You should probably save and restore the application's affinity mask
rather than assuming the mask is set to all CPUs.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Does Mesa have a policy for OpenGL token naming?

2018-06-25 Thread Nicholas Miell 
When extensions get promoted into OpenGL itself, they keep the same
token names minus the _EXT or whatever postfix, which means grepping for
the tokens in the OpenGL specification will find the implementation in
the Mesa source even if it still uses the original token names from the
extension.

Unfortunately, the OpenGL spec also gratuitously renames tokens on
occasion, which means e.g. the OpenGL 4.6 compatability spec discussion
of what used to be the EXT_fog_coord extension uses a completely
different set of token names than what's found in the Mesa source.

OpenGL 1.5 renames several tokens, 2.0 does one, 3.0 does a few, 3.2
does one, 4.1 does one, 4.2 has a Changed Tokens section that is empty,
4.3 does one, and 4.4 fixes the 4.2 Changed Tokens section to list a few
but does none for itself. The 4.2 changes are particularly weird because
they introduce new renamed tokens for some contexts but also retain the
old tokens for other contexts.

Does Mesa have a policy of which version of the tokens should be used in
the source?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Save and restore NV_fog_distance & FOG_COORD_SRC state

2018-06-25 Thread Nicholas Miell 
On 06/25/2018 12:04 PM, Ian Romanick wrote:
> On 06/25/2018 11:53 AM, Nicholas Miell wrote:
>> FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved
>> into display lists or restored on glPopAttrib(GL_FOG_BIT).
> 
> Good catch.  How did you detect this?  Do we have any test cases?
> 

I honestly don't remember, I've been sitting on this patch for years and
only dusted it off and updated it now that that there's an actual effort
to implement the 4.6 compat profile.

I think at some point I realized that my initial implementation of
NV_fog_distance was incomplete and at the same time I noticed that the
existing EXT_fog_coord implementation was broken in the same way.

Writing extension specs as a change list against the OpenGL spec is a
terrible way to convey information. The extensions adds entries to
tables, but don't mention that e.g. the table in question is the
comprehensive listing of all fog state or that elsewhere in the OpenGL
spec that table is referenced in the discussion of what must be saved by
PushAttrib.

>>
>> Signed-off-by: Nicholas Miell 
>> ---
>>  src/mesa/main/attrib.c | 4 
>>  src/mesa/main/dlist.c  | 2 ++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
>> index cbe93ab6faa..29d7089989e 100644
>> --- a/src/mesa/main/attrib.c
>> +++ b/src/mesa/main/attrib.c
>> @@ -1177,6 +1177,10 @@ _mesa_PopAttrib(void)
>> _mesa_Fogf(GL_FOG_END, fog->End);
>> _mesa_Fogf(GL_FOG_INDEX, fog->Index);
>> _mesa_Fogi(GL_FOG_MODE, fog->Mode);
>> +   _mesa_Fogi(GL_FOG_COORD_SRC, fog->FogCoordinateSource);
>> +
>> +   if (ctx->Extensions.NV_fog_distance)
>> + _mesa_Fogi(GL_FOG_DISTANCE_MODE_NV, fog->FogDistanceMode);
> 
> Presumably _mesa_PushAttrib already does the right thing?
> 

PushAttrib is just a memcpy of the gl_fog_attrib struct, so the
individual elements always get saved. Its only in PopAttrib where the
driver needs to be informed.

>>  }
>>  break;
>>   case GL_HINT_BIT:
>> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
>> index 4fc451000b5..8428791f9e8 100644
>> --- a/src/mesa/main/dlist.c
>> +++ b/src/mesa/main/dlist.c
>> @@ -2611,6 +2611,8 @@ save_Fogiv(GLenum pname, const GLint *params)
>> case GL_FOG_START:
>> case GL_FOG_END:
>> case GL_FOG_INDEX:
>> +   case GL_FOG_COORD_SRC:
>> +   case GL_FOG_DISTANCE_MODE_NV:
>>p[0] = (GLfloat) *params;
>>p[1] = 0.0f;
>>p[2] = 0.0f;
>>
> 

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

[Mesa-dev] [PATCH] mesa: Save and restore NV_fog_distance & FOG_COORD_SRC state

2018-06-25 Thread Nicholas Miell 
FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved
into display lists or restored on glPopAttrib(GL_FOG_BIT).

Signed-off-by: Nicholas Miell 
---
 src/mesa/main/attrib.c | 4 
 src/mesa/main/dlist.c  | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index cbe93ab6faa..29d7089989e 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1177,6 +1177,10 @@ _mesa_PopAttrib(void)
_mesa_Fogf(GL_FOG_END, fog->End);
_mesa_Fogf(GL_FOG_INDEX, fog->Index);
_mesa_Fogi(GL_FOG_MODE, fog->Mode);
+   _mesa_Fogi(GL_FOG_COORD_SRC, fog->FogCoordinateSource);
+
+   if (ctx->Extensions.NV_fog_distance)
+ _mesa_Fogi(GL_FOG_DISTANCE_MODE_NV, fog->FogDistanceMode);
 }
 break;
  case GL_HINT_BIT:
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 4fc451000b5..8428791f9e8 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -2611,6 +2611,8 @@ save_Fogiv(GLenum pname, const GLint *params)
case GL_FOG_START:
case GL_FOG_END:
case GL_FOG_INDEX:
+   case GL_FOG_COORD_SRC:
+   case GL_FOG_DISTANCE_MODE_NV:
   p[0] = (GLfloat) *params;
   p[1] = 0.0f;
   p[2] = 0.0f;
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] radv: Translate logic ops.

2018-05-13 Thread Nicholas Miell 

On 05/13/2018 06:14 PM, Bas Nieuwenhuizen wrote:

-#define V_028808_X_0X00 0x00
-#define V_028808_X_0X05 0x05
-#define V_028808_X_0X0A 0x0A
-#define V_028808_X_0X0F 0x0F
-#define V_028808_X_0X11 0x11
-#define V_028808_X_0X22 0x22
-#define V_028808_X_0X33 0x33
-#define V_028808_X_0X44 0x44
-#define V_028808_X_0X50 0x50
-#define V_028808_X_0X55 0x55
-#define V_028808_X_0X5A 0x5A
-#define V_028808_X_0X5F 0x5F
-#define V_028808_X_0X66 0x66
-#define V_028808_X_0X77 0x77
-#define V_028808_X_0X88 0x88
-#define V_028808_X_0X99 0x99
-#define V_028808_X_0XA0 0xA0
-#define V_028808_X_0XA5 0xA5
-#define V_028808_X_0XAA 0xAA
-#define V_028808_X_0XAF 0xAF
-#define V_028808_X_0XBB 0xBB
-#define V_028808_X_0XCC 0xCC
-#define V_028808_X_0XDD 0xDD
-#define V_028808_X_0XEE 0xEE
-#define V_028808_X_0XF0 0xF0
-#define V_028808_X_0XF5 0xF5
-#define V_028808_X_0XFA 0xFA
-#define V_028808_X_0XFF 0xFF
+#define V_028808_ROP3_CLEAR 0x00
+#define V_028808_ROP3_NOR   0x11
+#define V_028808_ROP3_AND_INVERTED  0x22
+#define V_028808_ROP3_COPY_INVERTED 0x33
+#define V_028808_ROP3_AND_REVERSE   0x44
+#define V_028808_ROP3_INVERT0x55
+#define V_028808_ROP3_XOR   0x66
+#define V_028808_ROP3_NAND  0x77
+#define V_028808_ROP3_AND   0x88
+#define V_028808_ROP3_EQUIVALENT0x99
+#define V_028808_ROP3_NO_OP 0xaa
+#define V_028808_ROP3_OR_INVERTED   0xbb
+#define V_028808_ROP3_COPY  0xcc
+#define V_028808_ROP3_OR_REVERSE0xdd
+#define V_028808_ROP3_OR0xee
+#define V_028808_ROP3_SET   0xff


This change removes names for some of the ternary raster operations 
supported by the hardware and also invents entirely new names for 
already named raster operations.


Also I think this header is generated?

If it isn't, perhaps the constants should be:

#define V_028808_ROP3_0_BLACKNESS   0x00
#define V_028808_ROP3_DPon  0x05
#define V_028808_ROP3_DPna  0x0A
#define V_028808_ROP3_Pn0x0F
#define V_028808_ROP3_DSon_NOTSRCERASE  0x11
#define V_028808_ROP3_DSna  0x22
#define V_028808_ROP3_Sn_NOTSRCCOPY 0x33
#define V_028808_ROP3_SDna_SRCERASE 0x44
#define V_028808_ROP3_PDna  0x50
#define V_028808_ROP3_Dn_DSTINVERT  0x55
#define V_028808_ROP3_DPx_PATINVERT 0x5A
#define V_028808_ROP3_DPan  0x5F
#define V_028808_ROP3_DSx_SRCINVERT 0x66
#define V_028808_ROP3_DSan  0x77
#define V_028808_ROP3_DSa_SRCAND0x88
#define V_028808_ROP3_DSxn  0x99
#define V_028808_ROP3_DPa   0xA0
#define V_028808_ROP3_PDxn  0xA5
#define V_028808_ROP3_D 0xAA
#define V_028808_ROP3_DPno

Re: [Mesa-dev] [PATCH] docs: add documentation for building with meson

2017-10-18 Thread Nicholas Miell 

On 10/17/2017 12:21 PM, Dylan Baker wrote:

+
+To see a description of your options you can run "meson configure". This will
+show your meson project configuration options as well as your local
+configuration options. One meson option to be aware of is that meson's default
+build type is "debug" (-O0 -g on gcc/clang).
+
+
+
+meson configure build
+
+


There should probably be a warning here about how there's no way to 
export a build configuration and how every minor or point update of 
meson requires you to delete your build directories and reconfigure 
everything from scratch.


Also how user-supplied C/C++ flags get merged in with Meson's idea of 
what the flags should be with the debug/debugoptimized/release 
configurations and if you want complete control of the build flags you 
should use the "plain" build type.

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

[Mesa-dev] [PATCH] Fix the xf86vm meson dependency

2017-10-17 Thread Nicholas Miell 
The pkg-config file is called xxf86vm.

Signed-off-by: Nicholas Miell <nmi...@gmail.com>
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 33121600d0c..82c4d2ed12c 100644
--- a/meson.build
+++ b/meson.build
@@ -678,7 +678,7 @@ if with_platform_x11
 dep_xdamage = dependency('xdamage', version : '>= 1.1')
 dep_xfixes = dependency('xfixes')
 dep_xcb_glx = dependency('xcb-glx', version : '>= 1.8.1')
-dep_xf86vm = dependency('xf86vm', required : false)
+dep_xf86vm = dependency('xxf86vm', required : false)
   endif
   if with_any_vk or (with_glx == 'dri' and with_dri_platform == 'drm')
 dep_xcb = dependency('xcb')
-- 
2.13.6

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

Re: [Mesa-dev] How to build 32-bit Mesa

2017-10-07 Thread Nicholas Miell 
On 10/07/2017 10:53 AM, Marek Olšák wrote:
> Would you please share how you build 32-bit Mesa on Linux. I think it
> would be useful to everybody.

1) Name your build directories e.g. BUILD.x86_64 or BUILD.i686. Put them both 
in the same directory.

2) Put -m32 or -m64 in the CFLAGS and CXXFLAGS environment variables when 
invoking configure.

3) Set the LLVM_CONFIG environment variable to /usr/bin/llvm-config-32 or -64 
when invoking configure

4) Invoke configure as "setarch i686 /path/to/configure" or "setarch x86_64 
/path/to/configure"

5) Test binaries with LD_LIBRARY_PATH='/path/to/BUILD.${PLATFORM}/lib' 
LIBGL_DRIVERS_PATH='/path/to/BUILD.${PLATFORM}/lib/gallium' /path/to/whatever
   The single quotes are important, ${PLATFORM} gets expanded to x86_64 or i686 
by ld-linux.so, not the shell.
   This allows you to run the Steam client with these variables set and both 
32-bit and 64-bit games work automatically.

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

Re: [Mesa-dev] [PATCH 1/6] meson: Build i965 and dri stack

2017-10-03 Thread Nicholas Miell 

On 10/03/2017 05:26 PM, Dylan Baker wrote:


diff --git a/meson_options.txt b/meson_options.txt
index eccd5c10d59..568903f1a0a 100644
--- a/meson_options.txt
+++ b/meson_options.txt



+option('valgrind',   type : 'boolean', vaule : true,


"vaule" typo.

"[PATCH 5/6] meson_options: Remove extra whitespace between parameters" 
also touches this line and does not fix the typo.


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

Re: [Mesa-dev] [PATCH 2/6] meson: build glx

2017-10-03 Thread Nicholas Miell 

On 10/03/2017 05:26 PM, Dylan Baker wrote:


diff --git a/meson_options.txt b/meson_options.txt
index 568903f1a0a..62d6b593f88 100644
--- a/meson_options.txt
+++ b/meson_options.txt



+option('glvnd',  type : 'boolean', vaule : false,


"vaule" again, although you fix this in "[PATCH 4/6] meson: build gbm" 
of this series.


I'm beginning to think that Meson should warn about unknown keys in 
dictionaries.

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

Re: [Mesa-dev] [PATCH] amd/addrlib: Rename the GB_ADDR_CONFIGs to GB_ADDR_CONFIG_{SI, GFX9}

2017-09-27 Thread Nicholas Miell 
On 09/27/2017 11:53 AM, Nicolai Hähnle wrote:
> On 27.09.2017 20:42, Nicholas Miell wrote:
>> Giving the same name to two different types violates the C++ One 
>> Definition
>> Rule and gcc will complain about it in LTO builds.
> 
> Oh my. What does the gcc warning look like? (I assume it's just a warning.)
> 

[5/5] Linking target src/amd/vulkan/libvulkan_radeon.so.
../src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h:39:7: warning: type ‘union 
GB_ADDR_CONFIG’ violates the C++ One Definition Rule [-Wodr]
 union GB_ADDR_CONFIG {
   ^
../src/amd/addrlib/inc/chip/r800/si_gb_reg.h:92:3: note: a different type is 
defined in another translation unit
 } GB_ADDR_CONFIG;
   ^
../src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h:74:7: note: the first difference 
of corresponding definitions is field ‘bitfields’
 } bitfields, bits;
   ^
../src/amd/addrlib/inc/chip/r800/si_gb_reg.h:90:25: note: a field with 
different name is defined in another translation unit
  unsigned int val : 32;

> Since these are auto-generated headers which are very much standardized 
> inside AMD, I'm hesitant to apply this particular patch. Certainly there 
> can't be a bug here in reality, since those are just dumb unions.
> 
> I think internally we'd rather want a namespace-based solution. Any 
> ideas? I need to reflect on this a bit...
> 
> Thanks,
> Nicolai
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] amd/addrlib: Rename the GB_ADDR_CONFIGs to GB_ADDR_CONFIG_{SI, GFX9}

2017-09-27 Thread Nicholas Miell 
Giving the same name to two different types violates the C++ One Definition
Rule and gcc will complain about it in LTO builds.

Signed-off-by: Nicholas Miell <nmi...@gmail.com>
---
 src/amd/addrlib/gfx9/gfx9addrlib.cpp| 2 +-
 src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h | 2 +-
 src/amd/addrlib/inc/chip/r800/si_gb_reg.h   | 2 +-
 src/amd/addrlib/r800/siaddrlib.cpp  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/amd/addrlib/gfx9/gfx9addrlib.cpp 
b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
index edb4c6e636a..6837e0a3d9b 100644
--- a/src/amd/addrlib/gfx9/gfx9addrlib.cpp
+++ b/src/amd/addrlib/gfx9/gfx9addrlib.cpp
@@ -992,7 +992,7 @@ BOOL_32 Gfx9Lib::HwlInitGlobalParams(
 
 if (m_settings.isArcticIsland)
 {
-GB_ADDR_CONFIG gbAddrConfig;
+GB_ADDR_CONFIG_GFX9 gbAddrConfig;
 
 gbAddrConfig.u32All = pCreateIn->regValue.gbAddrConfig;
 
diff --git a/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h 
b/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
index 823710cc189..d387dba2271 100644
--- a/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
+++ b/src/amd/addrlib/inc/chip/gfx9/gfx9_gb_reg.h
@@ -36,7 +36,7 @@
 #error "BIGENDIAN_CPU or LITTLEENDIAN_CPU must be defined"
 #endif
 
-union GB_ADDR_CONFIG {
+union GB_ADDR_CONFIG_GFX9 {
 struct {
 #ifdefined(LITTLEENDIAN_CPU)
 unsigned int   NUM_PIPES : 3;
diff --git a/src/amd/addrlib/inc/chip/r800/si_gb_reg.h 
b/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
index cf67f602bdf..99a2879048b 100644
--- a/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
+++ b/src/amd/addrlib/inc/chip/r800/si_gb_reg.h
@@ -89,7 +89,7 @@
 typedef union {
  unsigned int val : 32;
  GB_ADDR_CONFIG_T f;
-} GB_ADDR_CONFIG;
+} GB_ADDR_CONFIG_SI;
 
 #if   defined(LITTLEENDIAN_CPU)
 
diff --git a/src/amd/addrlib/r800/siaddrlib.cpp 
b/src/amd/addrlib/r800/siaddrlib.cpp
index 9ee1335b3ae..af794c2dbea 100644
--- a/src/amd/addrlib/r800/siaddrlib.cpp
+++ b/src/amd/addrlib/r800/siaddrlib.cpp
@@ -2239,7 +2239,7 @@ VOID SiLib::HwlSetupTileInfo(
 *   SiLib::DecodeGbRegs
 *
 *   @brief
-*   Decodes GB_ADDR_CONFIG and noOfBanks/noOfRanks
+*   Decodes GB_ADDR_CONFIG_SI and noOfBanks/noOfRanks
 *
 *   @return
 *   TRUE if all settings are valid
@@ -2249,7 +2249,7 @@ VOID SiLib::HwlSetupTileInfo(
 BOOL_32 SiLib::DecodeGbRegs(
 const ADDR_REGISTER_VALUE* pRegValue) ///< [in] create input
 {
-GB_ADDR_CONFIG  reg;
+GB_ADDR_CONFIG_SI  reg;
 BOOL_32 valid = TRUE;
 
 reg.val = pRegValue->gbAddrConfig;
-- 
2.13.5

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

Re: [Mesa-dev] [PATCH v2 4/4] meson: build "radv" vulkan driver for radeon hardware

2017-09-23 Thread Nicholas Miell 
On 09/23/2017 08:39 AM, Dylan Baker wrote:
> diff --git a/meson_options.txt b/meson_options.txt
> index e52cec31f11..854cba851d7 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -20,8 +20,10 @@
>   
>   option('platforms',  type : 'string',  value : 'x11,wayland',
>  description : 'comma separated list of window systems to support. 
> wayland, x11, surfaceless, drm, etc.')
> -option('vulkan-drivers', type : 'string',  value : 'intel',
> +option('vulkan-drivers', type : 'string',  value : 'intel,amd',
>  description : 'comma separated list of vulkan drivers to build.')
> +option('shader-cache',type : 'boolean', vaule : true,

"vaule" typo

> +   description : 'Build with on-disk shader cache support')
>   option('vulkan_icd_dir', type : 'string',  value : '',
>  description : 'Location relative to prefix to put vulkan icds on 
> install. Default: $datadir/vulkan/icd.d')
>   option('valgrind',   type : 'boolean', vaule : true,

and again.

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

[Mesa-dev] [PATCH] radv: Implement VK_AMD_rasterization_order

2017-09-18 Thread Nicholas Miell 
Tested with AMD's Anvil OutOfOrderRasterization demo on a RX 560.

Signed-off-by: Nicholas Miell <nmi...@gmail.com>
---
 src/amd/vulkan/radv_device.c   | 17 +
 src/amd/vulkan/radv_pipeline.c | 10 +-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index e6d595dfbe5..49536851bae 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -175,6 +175,14 @@ static const VkExtensionProperties 
common_device_extensions[] = {
.specVersion = 1,
},
 };
+
+static const VkExtensionProperties rasterization_order_extension[] ={
+   {
+   .extensionName = VK_AMD_RASTERIZATION_ORDER_EXTENSION_NAME,
+   .specVersion = 1,
+   },
+};
+
 static const VkExtensionProperties ext_sema_device_extensions[] = {
{
.extensionName = VK_KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME,
@@ -339,6 +347,15 @@ radv_physical_device_init(struct radv_physical_device 
*device,
if (result != VK_SUCCESS)
goto fail;
 
+   if (device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2) {
+   result = radv_extensions_register(instance,
+   >extensions,
+   rasterization_order_extension,
+   
ARRAY_SIZE(rasterization_order_extension));
+   if (result != VK_SUCCESS)
+   goto fail;
+   }
+
if (device->rad_info.has_syncobj) {
result = radv_extensions_register(instance,
  >extensions,
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 91577402a2c..8f20e902800 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -33,6 +33,7 @@
 #include "nir/nir.h"
 #include "nir/nir_builder.h"
 #include "spirv/nir_spirv.h"
+#include "vk_util.h"
 
 #include 
 #include 
@@ -1085,6 +1086,13 @@ radv_pipeline_init_multisample_state(struct 
radv_pipeline *pipeline,
ms->pa_sc_mode_cntl_1 |= 
EG_S_028A4C_PS_ITER_SAMPLE(ps_iter_samples > 1);
}
 
+   const struct VkPipelineRasterizationStateRasterizationOrderAMD 
*raster_order =
+   vk_find_struct_const(pCreateInfo->pRasterizationState->pNext, 
PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD);
+   if (raster_order && raster_order->rasterizationOrder == 
VK_RASTERIZATION_ORDER_RELAXED_AMD) {
+   ms->pa_sc_mode_cntl_1 |= 
S_028A4C_OUT_OF_ORDER_PRIMITIVE_ENABLE(1) |
+   S_028A4C_OUT_OF_ORDER_WATER_MARK(0x7);
+   }
+
if (vkms) {
if (vkms->alphaToCoverageEnable)
blend->db_alpha_to_mask |= 
S_028B70_ALPHA_TO_MASK_ENABLE(1);
@@ -1875,7 +1883,7 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
!ps->info.fs.writes_sample_mask)
pipeline->graphics.blend.spi_shader_col_format = 
V_028714_SPI_SHADER_32_R;
}
-   
+
unsigned z_order;
pipeline->graphics.db_shader_control = 0;
if (ps->info.fs.early_fragment_test || !ps->info.fs.writes_memory)
-- 
2.13.5

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

Re: [Mesa-dev] [PATCH v2 1/5] util/disk_cache: rename mesa cache dir and introduce cache versioning

2017-08-23 Thread Nicholas Miell 

On 08/23/2017 06:23 PM, Matt Turner wrote:

On Wed, Aug 23, 2017 at 2:32 AM, Timothy Arceri  wrote:

Steam is already analysing cache items


What does this mean?


Steam will attempt to download compiled shaders for your GPU and version 
of Mesa, or upload the shaders you compile locally if they're not 
already stored on Valve's servers.


How they verify shaders aren't malicious is an unanswered question.

You can disable this attack surface by setting the 
STEAM_ENABLE_SHADER_CACHE_MANAGEMENT environment variable to 0 before 
starting the Steam client.

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

Re: [Mesa-dev] [PATCH 1/2] util: Add utility build-id code.

2017-02-14 Thread Nicholas Miell 

On 02/14/2017 12:30 PM, Chad Versace wrote:

On Tue 14 Feb 2017, Matt Turner wrote:

Provides the ability to read the .note.gnu.build-id section of ELF
binaries, which is inserted by the --build-id=... flag to ld.
---
 configure.ac  |   2 +
 src/util/Makefile.sources |   2 +
 src/util/build_id.c   | 109 ++
 src/util/build_id.h   |  56 
 4 files changed, 169 insertions(+)
 create mode 100644 src/util/build_id.c
 create mode 100644 src/util/build_id.h




+AC_CHECK_FUNC([dl_iterate_phdr], [DEFINES="$DEFINES -DHAVE_DL_ITERATE_PHDR"])


Nice. I wasn't aware of dl_iterate_phdr(). My code for querying the
build-id was less slick. It used open(2) on the library, then manually
parsed the ElfW(Ehdr) and ElfW(Shdr) to find the build-id node.


I also reinvented the build ID lookup wheel and just to record this 
knowledge publicly for posterity:


The struct link_map l_addr field seems to corresponds to the struct 
dl_phdr_info dlpi_addr field.


You can retrieve the struct link_map for a symbol by passing the 
RTLD_DL_LINKMAP flag to dladdr1() or for a library handle returned by 
dlopen() by passing RTLD_DI_LINKMAP to dlinfo().


This means you can find the note section for a loaded library directly 
without having to resort to string comparisons against library names, 
which is probably more future-proof.

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

Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

2016-08-23 Thread Nicholas Miell 

On 08/23/2016 02:45 PM, Emil Velikov wrote:

On 23 August 2016 at 19:05, Nicholas Miell <nmi...@gmail.com> wrote:

On 08/23/2016 02:07 AM, Emil Velikov wrote:


Skimmed through the discussion and I'm not sure the above will be enough.

Since the user is free to place json files in $HOME/.local ... this
implies that they may _not_ have access to /usr or /etc. Thus as they
install the file (to say $HOME/foo/lib) the Vulkan loader will not be
able to pick it up.



Why not?

Stick the 32-bit library in $HOME/foo/lib, the 64-bit library in
$HOME/foo/lib64, set library_path to "/home/emil/foo/$LIB/lib_mygpu.so" in
the $HOME/.local/share/vulkan/icd.d/mygpu.json file, and it should work,
right?


Few reasons:
 - If you use $LIB you also need to provide for all arches supported
by your setup. otherwise the loader will for missing files (small
nitpick but still).


The loader already handles this case.


 - conflict of who provides the json file - is it the x86-64 or i386
package, both, neither etc.


Both, assuming your package manager supports it (rpm) or stick it in an 
architecture-neutral package that the architecture-specific packages 
require (deb).



 - the vulkan loader is based on the presumption that can be multiple
drivers on the system. Each one clearly distinguished and described in
it's own json. Thus as ABI changes (gets updated) we must mandate that
distributions and users update both 64 and 32bit packages at the same
time. Otherwise there will be a miss-match between the described ABI
in json and the actual one of the binary/ies.


That's how distributions and package managers work already.


Json update:
 - the same file _cannot_ be provided by multiple packages



RPM certainly allows this, as long as the packages that provide the file
have the same name & version, different architectures, and the files are
byte-identical. Sticking $LIB in the path instead of "lib" or "lib64" makes
the files byte-identical.



Not everyone uses RPM, or even a package manager all together. In any
distro (mostly for source based ones) having one package overwrite
files of another package, is a serious no go. It may be allowed by
that's an exception of the general rule, requiring it's own list with
"ifs and buts".

Real world example: your distro ships the 64bit ICD, but not a 32bit
one. You build and install the latter yourself and as
  - you remove it (because of reasons) you end up breaking your 64bit setup
 -  or, you update the 64bit package and the contents of the json
change in a way that they don't reflect/describe your 32bit ICD.


That isn't a real world example, or at the very least its an example of 
a bad distribution that you shouldn't use combined with user error.




So all in all, without separate json files each describing a separate
ICD, things are extremely easy to break.

-Emil



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

Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

2016-08-23 Thread Nicholas Miell 

On 08/23/2016 02:07 AM, Emil Velikov wrote:

Skimmed through the discussion and I'm not sure the above will be enough.

Since the user is free to place json files in $HOME/.local ... this
implies that they may _not_ have access to /usr or /etc. Thus as they
install the file (to say $HOME/foo/lib) the Vulkan loader will not be
able to pick it up.


Why not?

Stick the 32-bit library in $HOME/foo/lib, the 64-bit library in 
$HOME/foo/lib64, set library_path to "/home/emil/foo/$LIB/lib_mygpu.so" 
in the $HOME/.local/share/vulkan/icd.d/mygpu.json file, and it should 
work, right?



In theory one should be able to have a varying .json (one with and one
without the path) although the heuristics will be fragile due to the
varying $LIB (like the case of Debian and derivatives) and $DESTDIR.

So I see the following options:
 - new configure option - have to agree with Dave, please don't.
Furthermore we already have more than 50! of them.
 - fold the "w or w/o full path" under and existing option
(--enable-debug ?) - somewhat picky/fragile as well. Kind of OK for
short term solution.
 - use LD_LIBRARY_PATH - slightly annoying yet add once and forget
about it. OK-ish short term solution.
 - json update - the better long term solution imho.

Json update:
 - the same file _cannot_ be provided by multiple packages


RPM certainly allows this, as long as the packages that provide the file 
have the same name & version, different architectures, and the files are 
byte-identical. Sticking $LIB in the path instead of "lib" or "lib64" 
makes the files byte-identical.



 - thus we should use differently named files, but we should not rely
on the filename to determine arch/triple.
There has been no such recommendations/restrictions about the name so
starting now feels wrong.
 - so let's bump "file_format_version" - 1.0.1 or 1.1.0 ?
 - add ICD::arch tag and teach the loader to honour it. For json files
missing it we'll assume a "can be used on this platform" behaviour.
 - should we bother with the other parts of the triple or add it only
as need arise ?

With the above in place, one can have full path + filename for the
mutlilib setups. Old loaders will just get an error upon dlopen of
incompatible/wrong arch ICDs.

How do the above short/long term solutions sound ?

Thanks
Emil



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

Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

2016-08-22 Thread Nicholas Miell 

On 08/22/2016 04:10 PM, Julien Cristau wrote:

On Mon, Aug 22, 2016 at 14:18:51 -0700, Jason Ekstrand wrote:


On Mon, Aug 22, 2016 at 2:06 PM, Julien Cristau  wrote:


On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote:


Not providing a path allows the ICD to work on multi-arch systems but
breaks it if you install anywhere other than /usr/lib.  Given that users
may be installing locally in .local or similar, we probably do want to
provide a filename.  Distros can carry a revert of this commit if they

want

an intel_icd.json file without the path.


If a user is going to install stuff in .local, don't they have
LD_LIBRARY_PATH pointing there too?



Actually, no.  The loader will look for ICD files in
.local/share/vulkan/icd.d and the ICD file will point to the right .so.  It
should work out-of-the-box unless you either have a broken loader or we're
installing something wrong.


So somehow they're only building the vulkan driver but not libGL or
anything else?  Still, I guess a bunch of people will need both a 32bit
and a 64bit version of the driver.  How is the 64-bit
~/.local/share/vulkan/icd.d/intel_icd.json not going to clash with the
32-bit ~/.local/share/vulkan/icd.d/intel_icd.json?  I'm just not seeing
how this solves the problem...



To recap the IRC discussion:

ld-linux.so will expand $LIB to lib or lib64 as appropriate.

Unfortunately, Debian patches glibc to make $LIB expand to the target 
triple and there's no convenient way to figure out how $LIB expands at 
build time.


So you can just put $LIB in your architecture-independent ICD file and 
everything will work just fine, you just have to manually put the shared 
libraries in the appropriate location for your distribution.

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

Re: [Mesa-dev] [RFC] GLX_MESA_query_renderer

2013-03-01 Thread Nicholas Miell 
On 03/01/2013 03:14 PM, Ian Romanick wrote:
 New Procedures and Functions
 
 Bool glXQueryRendererIntegerMESA(Display *dpy, int screen,
  int renderer, int attribute,
  unsigned int *value);
 Bool glXQueryCurrentRendererIntegerMESA(int attribute, unsigned int
 *value);
 

Should these have ARB_robustness-style buffer size parameters?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Updated patches (v2)

2011-09-20 Thread Nicholas Miell 
The code formatting in translate_fog_distance_mode has been fixed. 

The NV10/NV20 patch isn't include this time around because it is still
untested and was only included in the first place in case the nouveau
people were interested.

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

[Mesa-dev] [PATCH 1/3] Add the basics for the NV_fog_distance extension

2011-09-20 Thread Nicholas Miell 
No driver implements it yet.
---
 src/mesa/main/extensions.c |1 +
 src/mesa/main/fog.c|   14 ++
 src/mesa/main/get.c|5 +
 src/mesa/main/mtypes.h |2 ++
 4 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 81bbca2..1416234 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -286,6 +286,7 @@ static const struct extension extension_table[] = {
{ GL_NV_blend_square, o(NV_blend_square), 
GL, 1999 },
{ GL_NV_conditional_render,   o(NV_conditional_render),   
GL, 2008 },
{ GL_NV_depth_clamp,  o(ARB_depth_clamp), 
GL, 2001 },
+   { GL_NV_fog_distance, o(NV_fog_distance), 
GL, 2001 },
{ GL_NV_fragment_program, o(NV_fragment_program), 
GL, 2001 },
{ GL_NV_fragment_program_option,  
o(NV_fragment_program_option),  GL, 2005 },
{ GL_NV_light_max_exponent,   o(NV_light_max_exponent),   
GL, 1999 },
diff --git a/src/mesa/main/fog.c b/src/mesa/main/fog.c
index 88aa31a..d65add9 100644
--- a/src/mesa/main/fog.c
+++ b/src/mesa/main/fog.c
@@ -172,6 +172,19 @@ _mesa_Fogfv( GLenum pname, const GLfloat *params )
 ctx-Fog.FogCoordinateSource = p;
 break;
   }
+  case GL_FOG_DISTANCE_MODE_NV: {
+GLenum p = (GLenum) (GLint) *params;
+ if (!ctx-Extensions.NV_fog_distance ||
+ (p != GL_EYE_RADIAL_NV  p != GL_EYE_PLANE  p != 
GL_EYE_PLANE_ABSOLUTE_NV)) {
+   _mesa_error(ctx, GL_INVALID_ENUM, glFog);
+   return;
+}
+if (ctx-Fog.FogDistanceMode == p)
+   return;
+FLUSH_VERTICES(ctx, _NEW_FOG);
+ctx-Fog.FogDistanceMode = p;
+break;
+  }
   default:
  _mesa_error( ctx, GL_INVALID_ENUM, glFog );
  return;
@@ -201,4 +214,5 @@ void _mesa_init_fog( struct gl_context * ctx )
ctx-Fog.ColorSumEnabled = GL_FALSE;
ctx-Fog.FogCoordinateSource = GL_FRAGMENT_DEPTH_EXT;
ctx-Fog._Scale = 1.0f;
+   ctx-Fog.FogDistanceMode = GL_EYE_PLANE_ABSOLUTE_NV;
 }
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 45b2777..2089a81 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -291,6 +291,7 @@ EXTRA_EXT(MESA_texture_array);
 EXTRA_EXT2(EXT_secondary_color, ARB_vertex_program);
 EXTRA_EXT(EXT_secondary_color);
 EXTRA_EXT(EXT_fog_coord);
+EXTRA_EXT(NV_fog_distance);
 EXTRA_EXT(EXT_texture_lod_bias);
 EXTRA_EXT(EXT_texture_filter_anisotropic);
 EXTRA_EXT(IBM_rasterpos_clip);
@@ -949,6 +950,10 @@ static const struct value_desc values[] = {
{ GL_FOG_COORDINATE_SOURCE_EXT, CONTEXT_ENUM(Fog.FogCoordinateSource),
  extra_EXT_fog_coord },
 
+   /* GL_NV_fog_distance */
+   { GL_FOG_DISTANCE_MODE_NV, CONTEXT_ENUM(Fog.FogDistanceMode),
+ extra_NV_fog_distance },
+
/* GL_IBM_rasterpos_clip */
{ GL_RASTER_POSITION_UNCLIPPED_IBM,
  CONTEXT_BOOL(Transform.RasterPositionUnclipped),
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 3b44ec6..7f019fc 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -905,6 +905,7 @@ struct gl_fog_attrib
GLboolean ColorSumEnabled;
GLenum FogCoordinateSource;  /** GL_EXT_fog_coord */
GLfloat _Scale; /** (End == Start) ? 1.0 : 1.0 / (End - Start) 
*/
+   GLenum FogDistanceMode; /** GL_NV_fog_distance */
 };
 
 
@@ -2901,6 +2902,7 @@ struct gl_extensions
GLboolean MESA_texture_array;
GLboolean NV_blend_square;
GLboolean NV_conditional_render;
+   GLboolean NV_fog_distance;
GLboolean NV_fragment_program;
GLboolean NV_fragment_program_option;
GLboolean NV_light_max_exponent;
-- 
1.7.6.2

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

[Mesa-dev] [PATCH 2/3] Add NV_fog_distance to the fixed-function vertex program generator

2011-09-20 Thread Nicholas Miell 
This is all that is needed to implement NV_fog_distance on programmable
hardware.
---
 src/mesa/main/ffvertex_prog.c |   43 +---
 1 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index 2d2485c..8469078 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -61,6 +61,7 @@ struct state_key {
unsigned rescale_normals:1;
 
unsigned fog_source_is_depth:1;
+   unsigned fog_distance_mode:2;
unsigned separate_specular:1;
unsigned point_attenuated:1;
unsigned point_array:1;
@@ -108,7 +109,22 @@ static GLuint translate_texgen( GLboolean enabled, GLenum 
mode )
}
 }
 
+#define FDM_EYE_RADIAL0
+#define FDM_EYE_PLANE 1
+#define FDM_EYE_PLANE_ABS 2
 
+static GLuint translate_fog_distance_mode( GLenum mode )
+{
+   switch (mode) {
+   case GL_EYE_RADIAL_NV:
+  return FDM_EYE_RADIAL;
+   case GL_EYE_PLANE:
+  return FDM_EYE_PLANE;
+   default: /* shouldn't happen; fall through to a sensible default */
+   case GL_EYE_PLANE_ABSOLUTE_NV:
+  return FDM_EYE_PLANE_ABS;
+   }
+}
 
 static GLboolean check_active_shininess( struct gl_context *ctx,
  const struct state_key *key,
@@ -205,8 +221,10 @@ static void make_state_key( struct gl_context *ctx, struct 
state_key *key )
if (ctx-Transform.RescaleNormals)
   key-rescale_normals = 1;
 
-   if (ctx-Fog.FogCoordinateSource == GL_FRAGMENT_DEPTH_EXT)
+   if (ctx-Fog.FogCoordinateSource == GL_FRAGMENT_DEPTH_EXT) {
   key-fog_source_is_depth = 1;
+  key-fog_distance_mode = 
translate_fog_distance_mode(ctx-Fog.FogDistanceMode);
+   }
 
if (ctx-Point._Attenuated)
   key-point_attenuated = 1;
@@ -1308,14 +1326,31 @@ static void build_fog( struct tnl_program *p )
struct ureg input;
 
if (p-state-fog_source_is_depth) {
-  input = get_eye_position_z(p);
+
+  switch (p-state-fog_distance_mode) {
+  case FDM_EYE_RADIAL: /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
+   input = get_eye_position(p);
+   emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
+   emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
+   emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
+   break;
+  case FDM_EYE_PLANE: /* Z = Ze */
+   input = get_eye_position_z(p);
+   emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
+   break;
+  case FDM_EYE_PLANE_ABS: /* Z = abs(Ze) */
+   input = get_eye_position_z(p);
+   emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
+   break;
+  default: assert(0); break; /* can't happen */
+  }
+
}
else {
   input = swizzle1(register_input(p, VERT_ATTRIB_FOG), X);
+  emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
}
 
-   /* result.fog = {abs(f),0,0,1}; */
-   emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
emit_op1(p, OPCODE_MOV, fog, WRITEMASK_YZW, get_identity_param(p));
 }
 
-- 
1.7.6.2

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

[Mesa-dev] [PATCH 3/3] Enable NV_fog_distance for Gallium drivers

2011-09-20 Thread Nicholas Miell 
The fixed-function generated vertex program is all that's needed for
Gallium drivers.
---
 src/mesa/state_tracker/st_extensions.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 108d7ae..bdc7dcc 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -295,6 +295,7 @@ void st_init_extensions(struct st_context *st)
ctx-Extensions.MESA_pack_invert = GL_TRUE;
 
ctx-Extensions.NV_blend_square = GL_TRUE;
+   ctx-Extensions.NV_fog_distance = GL_TRUE;
ctx-Extensions.NV_texgen_reflection = GL_TRUE;
ctx-Extensions.NV_texture_env_combine4 = GL_TRUE;
ctx-Extensions.NV_texture_rectangle = GL_TRUE;
-- 
1.7.6.2

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

[Mesa-dev] Implement NV_fog_distance for Gallium hardware

2011-09-19 Thread Nicholas Miell 
The NV_fog_distance extension allows you to specify how the fog distance
of a fragment is calculated. The usual method approximates the distance
of the fragment from the eye as the absolute value of the distance of
the fragment from the eye's Z plane. (Or, rather, the distance of each
vertex and then interpolated for each fragment.)

NV_fog_distance introduces the eye radial fog distance mode, which
calculates the actual distance from the eye to the vertex. Using the
actual distance avoids weird peripheral vision artifacts where the
rotation of eye causes previously invisible portions of the scene to
suddenly fade into visibility in a strange and unnatural fashion.

Direct3D 9 calls the eye radial fog distance mode range-based fog and
Wine's D3D9 implementation will use NV_fog_distance to implement it.
Several other open source game engines in Google Code Search use the eye
radial fog mode if it is available.

This has been tested with the R600 Gallium driver in Minecraft (with the
OptiFine mod). Extensively.

I also threw in an untested implementation for NV10 and NV20 GPUs. It
looked rather obvious based on the register and constant names and the
assumption that since NVIDIA wrote the extesion, their hardware does the
right thing. However, I have no way to test this so it is best left
unapplied until somebody who can test it does test it.

In theory this should be easy to add to the non-Gallium drivers for the
i965 and r600 and perhaps more difficult to add to the non-Gallium r300
driver (r300 appears to still implement fog in hardware), but I
personally don't care.

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

[Mesa-dev] [PATCH 1/5] Update llvmpipe's gitignore

2011-09-19 Thread Nicholas Miell 
---
 src/gallium/drivers/llvmpipe/.gitignore |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/.gitignore 
b/src/gallium/drivers/llvmpipe/.gitignore
index 6ebd2b8..ce96392 100644
--- a/src/gallium/drivers/llvmpipe/.gitignore
+++ b/src/gallium/drivers/llvmpipe/.gitignore
@@ -1,4 +1,5 @@
 lp_tile_soa.c
+lp_test_arit
 lp_test_blend
 lp_test_conv
 lp_test_format
-- 
1.7.6.2

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

[Mesa-dev] [PATCH 2/5] Add the basics for the NV_fog_distance extension

2011-09-19 Thread Nicholas Miell 
No driver implements it yet.
---
 src/mesa/main/extensions.c |1 +
 src/mesa/main/fog.c|   14 ++
 src/mesa/main/get.c|5 +
 src/mesa/main/mtypes.h |2 ++
 4 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 9cec15b..1755d68 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -289,6 +289,7 @@ static const struct extension extension_table[] = {
{ GL_NV_blend_square, o(NV_blend_square), 
GL, 1999 },
{ GL_NV_conditional_render,   o(NV_conditional_render),   
GL, 2008 },
{ GL_NV_depth_clamp,  o(ARB_depth_clamp), 
GL, 2001 },
+   { GL_NV_fog_distance, o(NV_fog_distance), 
GL, 2001 },
{ GL_NV_fragment_program, o(NV_fragment_program), 
GL, 2001 },
{ GL_NV_fragment_program_option,  
o(NV_fragment_program_option),  GL, 2005 },
{ GL_NV_light_max_exponent,   o(NV_light_max_exponent),   
GL, 1999 },
diff --git a/src/mesa/main/fog.c b/src/mesa/main/fog.c
index 88aa31a..d65add9 100644
--- a/src/mesa/main/fog.c
+++ b/src/mesa/main/fog.c
@@ -172,6 +172,19 @@ _mesa_Fogfv( GLenum pname, const GLfloat *params )
 ctx-Fog.FogCoordinateSource = p;
 break;
   }
+  case GL_FOG_DISTANCE_MODE_NV: {
+GLenum p = (GLenum) (GLint) *params;
+ if (!ctx-Extensions.NV_fog_distance ||
+ (p != GL_EYE_RADIAL_NV  p != GL_EYE_PLANE  p != 
GL_EYE_PLANE_ABSOLUTE_NV)) {
+   _mesa_error(ctx, GL_INVALID_ENUM, glFog);
+   return;
+}
+if (ctx-Fog.FogDistanceMode == p)
+   return;
+FLUSH_VERTICES(ctx, _NEW_FOG);
+ctx-Fog.FogDistanceMode = p;
+break;
+  }
   default:
  _mesa_error( ctx, GL_INVALID_ENUM, glFog );
  return;
@@ -201,4 +214,5 @@ void _mesa_init_fog( struct gl_context * ctx )
ctx-Fog.ColorSumEnabled = GL_FALSE;
ctx-Fog.FogCoordinateSource = GL_FRAGMENT_DEPTH_EXT;
ctx-Fog._Scale = 1.0f;
+   ctx-Fog.FogDistanceMode = GL_EYE_PLANE_ABSOLUTE_NV;
 }
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index a777bd8..0d56650 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -291,6 +291,7 @@ EXTRA_EXT(MESA_texture_array);
 EXTRA_EXT2(EXT_secondary_color, ARB_vertex_program);
 EXTRA_EXT(EXT_secondary_color);
 EXTRA_EXT(EXT_fog_coord);
+EXTRA_EXT(NV_fog_distance);
 EXTRA_EXT(EXT_texture_lod_bias);
 EXTRA_EXT(EXT_texture_filter_anisotropic);
 EXTRA_EXT(IBM_rasterpos_clip);
@@ -949,6 +950,10 @@ static const struct value_desc values[] = {
{ GL_FOG_COORDINATE_SOURCE_EXT, CONTEXT_ENUM(Fog.FogCoordinateSource),
  extra_EXT_fog_coord },
 
+   /* GL_NV_fog_distance */
+   { GL_FOG_DISTANCE_MODE_NV, CONTEXT_ENUM(Fog.FogDistanceMode),
+ extra_NV_fog_distance },
+
/* GL_IBM_rasterpos_clip */
{ GL_RASTER_POSITION_UNCLIPPED_IBM,
  CONTEXT_BOOL(Transform.RasterPositionUnclipped),
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 429c8b4..493f92c 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -906,6 +906,7 @@ struct gl_fog_attrib
GLboolean ColorSumEnabled;
GLenum FogCoordinateSource;  /** GL_EXT_fog_coord */
GLfloat _Scale; /** (End == Start) ? 1.0 : 1.0 / (End - Start) 
*/
+   GLenum FogDistanceMode; /** GL_NV_fog_distance */
 };
 
 
@@ -2903,6 +2904,7 @@ struct gl_extensions
GLboolean MESA_texture_array;
GLboolean NV_blend_square;
GLboolean NV_conditional_render;
+   GLboolean NV_fog_distance;
GLboolean NV_fragment_program;
GLboolean NV_fragment_program_option;
GLboolean NV_light_max_exponent;
-- 
1.7.6.2

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

[Mesa-dev] [PATCH 3/5] Add NV_fog_distance to the fixed-function vertex program generator

2011-09-19 Thread Nicholas Miell 
This is all that is needed to implement NV_fog_distance on programmable
hardware.
---
 src/mesa/main/ffvertex_prog.c |   40 
 1 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/ffvertex_prog.c b/src/mesa/main/ffvertex_prog.c
index 2d2485c..fc7b01a 100644
--- a/src/mesa/main/ffvertex_prog.c
+++ b/src/mesa/main/ffvertex_prog.c
@@ -61,6 +61,7 @@ struct state_key {
unsigned rescale_normals:1;
 
unsigned fog_source_is_depth:1;
+   unsigned fog_distance_mode:2;
unsigned separate_specular:1;
unsigned point_attenuated:1;
unsigned point_array:1;
@@ -108,7 +109,19 @@ static GLuint translate_texgen( GLboolean enabled, GLenum 
mode )
}
 }
 
+#define FDM_EYE_RADIAL0
+#define FDM_EYE_PLANE 1
+#define FDM_EYE_PLANE_ABS 2
 
+static GLuint translate_fog_distance_mode( GLenum mode )
+{
+   switch (mode) {
+   case GL_EYE_RADIAL_NV: return FDM_EYE_RADIAL;
+   case GL_EYE_PLANE: return FDM_EYE_PLANE;
+   default: /* shouldn't happen; fall through to a sensible default */
+   case GL_EYE_PLANE_ABSOLUTE_NV: return FDM_EYE_PLANE_ABS;
+   }
+}
 
 static GLboolean check_active_shininess( struct gl_context *ctx,
  const struct state_key *key,
@@ -205,8 +218,10 @@ static void make_state_key( struct gl_context *ctx, struct 
state_key *key )
if (ctx-Transform.RescaleNormals)
   key-rescale_normals = 1;
 
-   if (ctx-Fog.FogCoordinateSource == GL_FRAGMENT_DEPTH_EXT)
+   if (ctx-Fog.FogCoordinateSource == GL_FRAGMENT_DEPTH_EXT) {
   key-fog_source_is_depth = 1;
+  key-fog_distance_mode = 
translate_fog_distance_mode(ctx-Fog.FogDistanceMode);
+   }
 
if (ctx-Point._Attenuated)
   key-point_attenuated = 1;
@@ -1308,14 +1323,31 @@ static void build_fog( struct tnl_program *p )
struct ureg input;
 
if (p-state-fog_source_is_depth) {
-  input = get_eye_position_z(p);
+
+  switch (p-state-fog_distance_mode) {
+  case FDM_EYE_RADIAL: /* Z = sqrt(Xe*Xe + Ye*Ye + Ze*Ze) */
+   input = get_eye_position(p);
+   emit_op2(p, OPCODE_DP3, fog, WRITEMASK_X, input, input);
+   emit_op1(p, OPCODE_RSQ, fog, WRITEMASK_X, fog);
+   emit_op1(p, OPCODE_RCP, fog, WRITEMASK_X, fog);
+   break;
+  case FDM_EYE_PLANE: /* Z = Ze */
+   input = get_eye_position_z(p);
+   emit_op1(p, OPCODE_MOV, fog, WRITEMASK_X, input);
+   break;
+  case FDM_EYE_PLANE_ABS: /* Z = abs(Ze) */
+   input = get_eye_position_z(p);
+   emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
+   break;
+  default: assert(0); break; /* can't happen */
+  }
+
}
else {
   input = swizzle1(register_input(p, VERT_ATTRIB_FOG), X);
+  emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
}
 
-   /* result.fog = {abs(f),0,0,1}; */
-   emit_op1(p, OPCODE_ABS, fog, WRITEMASK_X, input);
emit_op1(p, OPCODE_MOV, fog, WRITEMASK_YZW, get_identity_param(p));
 }
 
-- 
1.7.6.2

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

[Mesa-dev] [PATCH 4/5] Enable NV_fog_distance for Gallium drivers

2011-09-19 Thread Nicholas Miell 
The fixed-function generated vertex program is all that's needed for
Gallium drivers.
---
 src/mesa/state_tracker/st_extensions.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 722db8d..9266eec 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -296,6 +296,7 @@ void st_init_extensions(struct st_context *st)
ctx-Extensions.MESA_pack_invert = GL_TRUE;
 
ctx-Extensions.NV_blend_square = GL_TRUE;
+   ctx-Extensions.NV_fog_distance = GL_TRUE;
ctx-Extensions.NV_texgen_reflection = GL_TRUE;
ctx-Extensions.NV_texture_env_combine4 = GL_TRUE;
ctx-Extensions.NV_texture_rectangle = GL_TRUE;
-- 
1.7.6.2

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

[Mesa-dev] [PATCH 5/5] UNTESTED: Enable NV_fog_distance on NV10 and NV20 hardware

2011-09-19 Thread Nicholas Miell 
This has not been tested on real hardware. I have no idea if it works.

Add support for NV_fog_distance to the NV10 and NV20 drivers.
---
 src/mesa/drivers/dri/nouveau/nv10_context.c   |1 +
 src/mesa/drivers/dri/nouveau/nv10_state_tnl.c |   14 +++---
 src/mesa/drivers/dri/nouveau/nv20_context.c   |1 +
 src/mesa/drivers/dri/nouveau/nv20_state_tnl.c |   14 +++---
 4 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/nouveau/nv10_context.c 
b/src/mesa/drivers/dri/nouveau/nv10_context.c
index da0ef2b..c4dc1c5 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_context.c
@@ -435,6 +435,7 @@ nv10_context_create(struct nouveau_screen *screen, const 
struct gl_config *visua
ctx-Extensions.ARB_texture_env_crossbar = true;
ctx-Extensions.ARB_texture_env_combine = true;
ctx-Extensions.ARB_texture_env_dot3 = true;
+   ctx-Extensions.NV_fog_distance = true;
ctx-Extensions.NV_texture_rectangle = true;
 
/* GL constants. */
diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_tnl.c 
b/src/mesa/drivers/dri/nouveau/nv10_state_tnl.c
index 96d1b32..aa261ec 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_state_tnl.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_state_tnl.c
@@ -80,13 +80,21 @@ get_fog_mode(unsigned mode)
 }
 
 static unsigned
-get_fog_source(unsigned source)
+get_fog_source_and_distance_mode(unsigned source, unsigned distance_mode)
 {
switch (source) {
case GL_FOG_COORDINATE_EXT:
return NV10_3D_FOG_COORD_FOG;
case GL_FRAGMENT_DEPTH_EXT:
-   return NV10_3D_FOG_COORD_DIST_ORTHOGONAL_ABS;
+   switch (distance_mode) {
+   case GL_EYE_PLANE_ABSOLUTE_NV:
+   return NV10_3D_FOG_COORD_DIST_ORTHOGONAL_ABS;
+   case GL_EYE_PLANE:
+   return NV10_3D_FOG_COORD_DIST_ORTHOGONAL;
+   case GL_EYE_RADIAL_NV:
+   return NV10_3D_FOG_COORD_DIST_RADIAL;
+   default: assert(0);
+   }
default:
assert(0);
}
@@ -135,7 +143,7 @@ nv10_emit_fog(struct gl_context *ctx, int emit)
 
BEGIN_RING(chan, celsius, NV10_3D_FOG_MODE, 4);
OUT_RING(chan, get_fog_mode(f-Mode));
-   OUT_RING(chan, get_fog_source(source));
+   OUT_RING(chan, get_fog_source_and_distance_mode(source, 
f-FogDistanceMode));
OUT_RINGb(chan, f-Enabled);
OUT_RING(chan, pack_rgba_f(MESA_FORMAT_RGBA_REV, f-Color));
 
diff --git a/src/mesa/drivers/dri/nouveau/nv20_context.c 
b/src/mesa/drivers/dri/nouveau/nv20_context.c
index 87a6db1..2a883e3 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_context.c
@@ -449,6 +449,7 @@ nv20_context_create(struct nouveau_screen *screen, const 
struct gl_config *visua
ctx-Extensions.ARB_texture_env_crossbar = true;
ctx-Extensions.ARB_texture_env_combine = true;
ctx-Extensions.ARB_texture_env_dot3 = true;
+   ctx-Extensions.NV_fog_distance = true;
ctx-Extensions.NV_texture_rectangle = true;
 
/* GL constants. */
diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_tnl.c 
b/src/mesa/drivers/dri/nouveau/nv20_state_tnl.c
index 4f7ddd8..eaaec44 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_state_tnl.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_state_tnl.c
@@ -127,13 +127,21 @@ get_fog_mode_unsigned(unsigned mode)
 }
 
 static unsigned
-get_fog_source(unsigned source)
+get_fog_source_and_distance_mode(unsigned source, unsigned distance_mode)
 {
switch (source) {
case GL_FOG_COORDINATE_EXT:
return NV20_3D_FOG_COORD_FOG;
case GL_FRAGMENT_DEPTH_EXT:
-   return NV20_3D_FOG_COORD_DIST_ORTHOGONAL_ABS;
+   switch (distance_mode) {
+   case GL_EYE_PLANE_ABSOLUTE_NV:
+   return NV20_3D_FOG_COORD_DIST_ORTHOGONAL_ABS;
+   case GL_EYE_PLANE:
+   return NV20_3D_FOG_COORD_DIST_ORTHOGONAL;
+   case GL_EYE_RADIAL_NV:
+   return NV20_3D_FOG_COORD_DIST_RADIAL;
+   default: assert(0);
+   }
default:
assert(0);
}
@@ -156,7 +164,7 @@ nv20_emit_fog(struct gl_context *ctx, int emit)
OUT_RING(chan, (source == GL_FOG_COORDINATE_EXT ?
get_fog_mode_signed(f-Mode) :
get_fog_mode_unsigned(f-Mode)));
-   OUT_RING(chan, get_fog_source(source));
+   OUT_RING(chan, get_fog_source_and_distance_mode(source, 
f-FogDistanceMode));
OUT_RINGb(chan, f-Enabled);
OUT_RING(chan, pack_rgba_f(MESA_FORMAT_RGBA_REV, f-Color));
 
-- 
1.7.6.2

___
mesa-dev mailing list

Re: [Mesa-dev] Implement NV_fog_distance for Gallium hardware

2011-09-19 Thread Nicholas Miell 
On 09/19/2011 10:23 AM, Ian Romanick wrote:
 
 I guess the big question is... why?  With vertex shaders, this
 functionality is not terribly useful.  Over the past few weeks we've
 been *removing* code like this, so it seems kind of odd to add some of
 it.  If I'm not mistaken, the only hardware in Mesa that can do this
 but not vertex shaders is NV10.  Is it really that helpful?
 
 I'm not necessarily opposed to adding this, I just want to be sure
 we're giving it full thought... that's all.
 

Good question. In the general case, I'd agree with you that implementing
ancient extensions is a waste of effort, but this one is (AFAICT) an
extremely low impact change that benefits a number of existing projects.
It even has new code being written to target it, oddly enough (which is
what prompted my interest in the first place).

My first pass at this actually skipped the extension entirely and just
changed the generated vertex program to always use the eye radial
distance, but I figured that a full implementation of the extension
would be the correct thing to do, especially when there may be some
program out in the wild that breaks if the fog distance isn't abs(Ze).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev