Re: [Mesa-dev] [PATCH 0/5] radeon: Write-combined CPU mappings of BOs in GTT
Am 23.07.2014 05:54, schrieb Michel Dänzer: On 21.07.2014 17:07, Christian König wrote: Am 19.07.2014 03:15, schrieb Michel Dänzer: On 19.07.2014 00:47, Christian König wrote: Am 18.07.2014 05:07, schrieb Michel Dänzer: [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI I'm still not very keen with this change since I still don't understand the reason why it's faster than with GTT. Definitely needs more testing on a wider range of systems. Sure. If anyone wants to give this patch a spin and see if they can measure any performance difference, good or bad, that would be interesting. Maybe limit it to APUs for now? But IIRC, CPU writes to VRAM vs. write-combined GTT are actually an even bigger win with dedicated GPUs than with the Kaveri built-in GPU on my system. I suspect it may depend on the bandwidth available for PCIe vs. system memory though. I've made a few tests today with the kernel part of the patches running Xonotic on Ultra in 1920 x 1080. Without any patches I get around ~47.0fps on average with my dedicated HD7870. Adding only "drm/radeon: Use write-combined CPU mappings of rings and IBs on >= SI" and that goes down to ~45.3fps. Adding on to off that "drm/radeon: Use VRAM for indirect buffers on >= SI" and the frame rate goes down to ~27.74fps. Hmm, looks like I'll need to do more benchmarking of 3D workloads as well. I haven't been able to consistently[0] measure any significant difference between all placements of the rings and IBs with Xonotic or Reaction Quake with my Bonaire. I'd expect Xonotic to be shader / GPU memory bandwidth bound rather than CS bound anyway, so a ~40% hit from that kernel patch alone is very surprising. Are you sure it wasn't just the same kind of variation as described below? Yes, I've measured that multiple times and the results where quite consistent. But I didn't measured it on a Bonaire, where the bottleneck probably isn't the CPU load. I measured it on a fast Pitcairn and there Xonotic was clearly affected by the patches. [0] There were slightly different results sometimes, but next time I tried the same setup again, it was back to the same as always. So it seemed to depend more on the particular system boot / test run / moon phase / ... than the kernel patches themselves. Alex, given those numbers, it's probably best if you remove the "Use write-combined CPU mappings of rings and IBs on >= SI" change from your tree as well for now. I wouldn't go as far as reverting the patch. It just needs a bit more fine tuning and that can happen in the 3.17rc cycle. There's no need to revert it, just drop it from the tree. I'd still prefer that for now. My tests clearly show that we still can use USWC for the ring buffer on SI and probably earlier chips as well. Yeah, that might be the safest approach for now. How about using USWC for the rings on all chips since R600 and for the IB only on CIK? As far as I can see that should do the trick quite well. Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/5] r600g, radeonsi: Use write-combined persistent GTT mappings
On 18.07.2014 20:45, Marek Olšák wrote: > If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the > patch is okay. AFAICT GL_MAP_COHERENT_BIT simply means the app doesn't need to call glMemoryBarrier() to ensure coherency between access to the mapping and GL commands. Since we don't need to do anything for glMemoryBarrier(), GL_MAP_COHERENT_BIT doesn't make any difference for us. That said, I think I need to add code in the kernel ensuring we always flush the HDP cache before submitting a command stream to the hardware, bump the minor version, and only use VRAM for streaming when the DRM minor version is >= the bumped version. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Doubt about Streamed Vertex Buffer Write message descriptor in SandyBridge
On Tue, 2014-07-22 at 19:40 -0700, Kenneth Graunke wrote: > On Tuesday, July 22, 2014 11:38:05 AM Ilia Mirkin wrote: > > On Tue, Jul 22, 2014 at 11:25 AM, Samuel Iglesias Gonsálvez > > wrote: > > > Hello, > > > > > > I have a doubt related to Streamed Vertex Buffer Write message and its > > > message descriptor in SandyBridge. > > > > > > Reading about Stream Output Primitives Written > > > (snb_ihd_os_vol2_part1.pdf, pag 175), it says the following: > > > > > > "Whenever a GS thread outputs a DataPort Streamed Vertex Buffer Write > > > (SVBWrite) message with the Increment Num Prims Written bit set, the > > > SO_NUM_PRIMS_WRITTEN register will be incremented." > > > > > > According to SNB's spec [0], all the bits in the SVBWrite message > > > descriptor are ignored and I have not found the definition of this bit > > > in the documentation. Maybe I'm running the wrong pdfgrep command :-/ > > > > > > After doing some Google searches, I found that in other doc [1] it's > > > mentioned the "Increment Num Prims Written" bit inside the SVBWrite > > > message descriptor is not ignored for SNB (at least, it doesn't say that > > > explicitly). > > > > > > Do you know where is the "Increment Num Prims Written" bit defined in > > > SNB's doc? > > > > Not 100% sure if this is what you're looking for, but take a look at > > > > https://01.org/linuxgraphics/sites/default/files/documentation/snb_ihd_os_vol4_part2.pdf > > > > Page 23, 2.4.3.1 - SONumPrimsWritten and/or Page 29 - 2.4.4.1 > > NumGSPrimsGenerated and perhaps some of the other fields in the > > FF_SYNC message. > > > > Or wait until someone who knows what they're talking about replies :) > > > > -ilia > > What Ilia said :) > > It looks like SO_PRIM_STORAGE_NEEDED is updated by FF_SYNC messages, and > SO_NUM_PRIMS_WRITTEN is incremented by the URB_WRITE message (not SVB writes). > > Every GS thread terminates with a URB write message - apparently, there's a > field in the URB write message header (not descriptor) which determines how > much the counter should be incremented by. > > It looks like you /used/ to increment both counters via SVBWrite messages on > GM45 (SNB PRM, Volume 2, Part 1, Page 57), but that changed. Thanks for the info :) Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] radeon: Write-combined CPU mappings of BOs in GTT
On 21.07.2014 17:07, Christian König wrote: > Am 19.07.2014 03:15, schrieb Michel Dänzer: >> On 19.07.2014 00:47, Christian König wrote: >>> Am 18.07.2014 05:07, schrieb Michel Dänzer: >> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI > I'm still not very keen with this change since I still don't > understand > the reason why it's faster than with GTT. Definitely needs more > testing > on a wider range of systems. Sure. If anyone wants to give this patch a spin and see if they can measure any performance difference, good or bad, that would be interesting. > Maybe limit it to APUs for now? But IIRC, CPU writes to VRAM vs. write-combined GTT are actually an even bigger win with dedicated GPUs than with the Kaveri built-in GPU on my system. I suspect it may depend on the bandwidth available for PCIe vs. system memory though. >>> I've made a few tests today with the kernel part of the patches running >>> Xonotic on Ultra in 1920 x 1080. >>> >>> Without any patches I get around ~47.0fps on average with my dedicated >>> HD7870. >>> >>> Adding only "drm/radeon: Use write-combined CPU mappings of rings and >>> IBs on >= SI" and that goes down to ~45.3fps. >>> >>> Adding on to off that "drm/radeon: Use VRAM for indirect buffers on >= >>> SI" and the frame rate goes down to ~27.74fps. >> Hmm, looks like I'll need to do more benchmarking of 3D workloads as >> well. I haven't been able to consistently[0] measure any significant difference between all placements of the rings and IBs with Xonotic or Reaction Quake with my Bonaire. I'd expect Xonotic to be shader / GPU memory bandwidth bound rather than CS bound anyway, so a ~40% hit from that kernel patch alone is very surprising. Are you sure it wasn't just the same kind of variation as described below? [0] There were slightly different results sometimes, but next time I tried the same setup again, it was back to the same as always. So it seemed to depend more on the particular system boot / test run / moon phase / ... than the kernel patches themselves. >> Alex, given those numbers, it's probably best if you remove the "Use >> write-combined CPU mappings of rings and IBs on >= SI" change from your >> tree as well for now. > > I wouldn't go as far as reverting the patch. It just needs a bit more > fine tuning and that can happen in the 3.17rc cycle. There's no need to revert it, just drop it from the tree. I'd still prefer that for now. > My tests clearly show that we still can use USWC for the ring buffer on > SI and probably earlier chips as well. Yeah, that might be the safest approach for now. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Add an accelerated version of F_TO_I for x86_64
According to a quick micro-benchmark, this new version is 20% faster on my
Haswell laptop.
v2: Removed the XXX note about x86_64 from the comment
Signed-off-by: Jason Ekstrand
---
src/mesa/main/imports.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index af780b2..c8ae7f2 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -277,7 +277,6 @@ static inline int IROUND_POS(float f)
/**
* Convert float to int using a fast method. The rounding mode may vary.
- * XXX We could use an x86-64/SSE2 version here.
*/
static inline int F_TO_I(float f)
{
@@ -285,6 +284,10 @@ static inline int F_TO_I(float f)
int r;
__asm__ ("fistpl %0" : "=m" (r) : "t" (f) : "st");
return r;
+#elif defined(USE_X86_64_ASM) && defined(__GNUC__)
+ int r;
+ __asm__ ("cvtss2si %1, %0" : "=r" (r) : "xm" (f));
+ return r;
#elif defined(USE_X86_ASM) && defined(_MSC_VER)
int r;
_asm {
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Doubt about Streamed Vertex Buffer Write message descriptor in SandyBridge
On Tuesday, July 22, 2014 11:38:05 AM Ilia Mirkin wrote: > On Tue, Jul 22, 2014 at 11:25 AM, Samuel Iglesias Gonsálvez > wrote: > > Hello, > > > > I have a doubt related to Streamed Vertex Buffer Write message and its > > message descriptor in SandyBridge. > > > > Reading about Stream Output Primitives Written > > (snb_ihd_os_vol2_part1.pdf, pag 175), it says the following: > > > > "Whenever a GS thread outputs a DataPort Streamed Vertex Buffer Write > > (SVBWrite) message with the Increment Num Prims Written bit set, the > > SO_NUM_PRIMS_WRITTEN register will be incremented." > > > > According to SNB's spec [0], all the bits in the SVBWrite message > > descriptor are ignored and I have not found the definition of this bit > > in the documentation. Maybe I'm running the wrong pdfgrep command :-/ > > > > After doing some Google searches, I found that in other doc [1] it's > > mentioned the "Increment Num Prims Written" bit inside the SVBWrite > > message descriptor is not ignored for SNB (at least, it doesn't say that > > explicitly). > > > > Do you know where is the "Increment Num Prims Written" bit defined in > > SNB's doc? > > Not 100% sure if this is what you're looking for, but take a look at > > https://01.org/linuxgraphics/sites/default/files/documentation/snb_ihd_os_vol4_part2.pdf > > Page 23, 2.4.3.1 - SONumPrimsWritten and/or Page 29 - 2.4.4.1 > NumGSPrimsGenerated and perhaps some of the other fields in the > FF_SYNC message. > > Or wait until someone who knows what they're talking about replies :) > > -ilia What Ilia said :) It looks like SO_PRIM_STORAGE_NEEDED is updated by FF_SYNC messages, and SO_NUM_PRIMS_WRITTEN is incremented by the URB_WRITE message (not SVB writes). Every GS thread terminates with a URB write message - apparently, there's a field in the URB write message header (not descriptor) which determines how much the counter should be incremented by. It looks like you /used/ to increment both counters via SVBWrite messages on GM45 (SNB PRM, Volume 2, Part 1, Page 57), but that changed. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov wrote:
> On 21/07/14 17:02, Giovanni Campagna wrote:
>> On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov
>> wrote:
>>> Giovanni can you test the series that I've not butchered anything else
>>> during
>>> the rebase ?
>>
>> Oh hey, sorry I missed the bit that I was expected to test the patches.
>> Unfortunately, something indeed got lost: the logic to choose the
>> kms_swrast driver in preference to the swrast one.
>>
>> In my patches, I had:
>>
>> static int
>> dri_screen_create_sw(struct gbm_dri_device *dri)
>> {
>>int ret;
>>
>>ret = dri_screen_create_dri2(dri, "kms_swrast");
>>if (ret == 0)
>> return ret;
>>
>>return dri_screen_create_swrast(dri);
>> }
>>
>> That would take the place of dri_screen_create_swrast in the
>> dri_device_create() call site.
>> With your patches, the kms_swrast driver is effectively never loaded.
>>
> Am I day-dreaming, or is this the same as your initial concern as stated here
> [0] ? If so I believe that this should be fully addressed with the follow-up
> revision of patches 1 [1] & 2 [2].
>
> Perhaps the updated patches never made it to your inbox :'(
My bad, I was testing the old patch.
Nevertheless, the new patch is not working either: after the
megadrivers work, the new kms_swrast_dri is trying to load ilo when
run on an intel card with GBM_ALWAYS_SOFTWARE, because
loader_get_pci_from_fd() returns i965. This fails because ilo is not
compiled in (and even if ilo was compiled, it would fail because ilo
does not support my GM45).
Then weston crashes using the swrast driver, because at that point the
kms_swrast driver was already partially loaded and extensions bound
(so it takes a mixture of swrast and dri2 paths).
On intel, this problem can be worked around by removing the
LOADER_GALLIUM from the i965 entry in the pci_id_driver_map table, but
on nouveau/r600g/radeonsi it would result on a working GBM, HW
accelerated despite the environment variable. I believe the
_getDriverExtension_kms_swrast() function should return a different
extension table for kms_swrast (one that references a InitScreen that
always initializes a kms_swrast screen).
Additionally, it's probably a bad idea to fallback to kms_swrast
unconditionally, because kms_swrast will fail spectacularly on x11 or
wayland.
OTOH, once loaded the driver works fine.
Giovanni
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] gallium: add basic support for BPTC formats
Signed-off-by: Ilia Mirkin
---
So... the pack/unpack functions just assert. As far as I can tell, these are
entirely unused until e.g. softpipe or llvmpipe try to make use of this
format. Whoever adds bptc texturing support to those drivers can add the
mesa/texstore integration.
src/gallium/auxiliary/Makefile.sources | 1 +
src/gallium/auxiliary/util/u_format.c| 5 ++
src/gallium/auxiliary/util/u_format.csv | 6 ++
src/gallium/auxiliary/util/u_format.h| 8 +-
src/gallium/auxiliary/util/u_format_bptc.c | 26 +++
src/gallium/auxiliary/util/u_format_bptc.h | 109 +++
src/gallium/auxiliary/util/u_format_pack.py | 2 +-
src/gallium/auxiliary/util/u_format_table.py | 3 +-
src/gallium/include/pipe/p_format.h | 5 ++
9 files changed, 162 insertions(+), 3 deletions(-)
create mode 100644 src/gallium/auxiliary/util/u_format_bptc.c
create mode 100644 src/gallium/auxiliary/util/u_format_bptc.h
diff --git a/src/gallium/auxiliary/Makefile.sources
b/src/gallium/auxiliary/Makefile.sources
index 8919783..8b06c4f 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -113,6 +113,7 @@ C_SOURCES := \
util/u_format_s3tc.c \
util/u_format_rgtc.c \
util/u_format_etc.c \
+ util/u_format_bptc.c \
util/u_format_tests.c \
util/u_format_yuv.c \
util/u_format_zs.c \
diff --git a/src/gallium/auxiliary/util/u_format.c
b/src/gallium/auxiliary/util/u_format.c
index a53ed6f..cf355e5 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -496,6 +496,11 @@ util_format_fits_8unorm(const struct
util_format_description *format_desc)
format_desc->format == PIPE_FORMAT_LATC2_SNORM)
return FALSE;
return TRUE;
+ case UTIL_FORMAT_LAYOUT_BPTC:
+ if (format_desc->format == PIPE_FORMAT_BPTC_RGBA_UNORM ||
+ format_desc->format == PIPE_FORMAT_BPTC_SRGBA_UNORM)
+ return TRUE;
+ return FALSE;
case UTIL_FORMAT_LAYOUT_PLAIN:
/*
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index 8aa5c36..570ea5a 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -160,6 +160,7 @@ PIPE_FORMAT_R8G8Bx_SNORM , other, 1, 1, sn8
, sn8 , , , x
# - http://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt
# - http://www.opengl.org/registry/specs/ARB/texture_compression_rgtc.txt
# - http://www.opengl.org/registry/specs/EXT/texture_compression_latc.txt
+# - http://www.opengl.org/registry/specs/ARB/texture_compression_bptc.txt
# -
http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_ETC1_RGB8_texture.txt
# - http://msdn.microsoft.com/en-us/library/bb694531.aspx
PIPE_FORMAT_DXT1_RGB , s3tc, 4, 4, x64 , , , , xyz1,
rgb
@@ -183,6 +184,11 @@ PIPE_FORMAT_LATC2_SNORM , rgtc, 4, 4, x128,
, , , xxxy, rg
PIPE_FORMAT_ETC1_RGB8 , etc, 4, 4, x64, , , , xyz1,
rgb
+PIPE_FORMAT_BPTC_RGBA_UNORM , bptc, 4, 4, x128, , , , xyzw,
rgb
+PIPE_FORMAT_BPTC_SRGBA_UNORM , bptc, 4, 4, x128, , , , xyzw,
srgb
+PIPE_FORMAT_BPTC_RGB_FLOAT, bptc, 4, 4, x128, , , , xyz1,
rgb
+PIPE_FORMAT_BPTC_RGB_UFLOAT , bptc, 4, 4, x128, , , , xyz1,
rgb
+
# Straightforward D3D10-like formats (also used for
# vertex buffer element description)
#
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index 2e2bf02..1789a28 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -79,9 +79,14 @@ enum util_format_layout {
UTIL_FORMAT_LAYOUT_ETC = 6,
/**
+* BC6/7 Texture Compression
+*/
+ UTIL_FORMAT_LAYOUT_BPTC = 7,
+
+ /**
* Everything else that doesn't fit in any of the above layouts.
*/
- UTIL_FORMAT_LAYOUT_OTHER = 7
+ UTIL_FORMAT_LAYOUT_OTHER = 8
};
@@ -475,6 +480,7 @@ util_format_is_compressed(enum pipe_format format)
case UTIL_FORMAT_LAYOUT_S3TC:
case UTIL_FORMAT_LAYOUT_RGTC:
case UTIL_FORMAT_LAYOUT_ETC:
+ case UTIL_FORMAT_LAYOUT_BPTC:
/* XXX add other formats in the future */
return TRUE;
default:
diff --git a/src/gallium/auxiliary/util/u_format_bptc.c
b/src/gallium/auxiliary/util/u_format_bptc.c
new file mode 100644
index 000..8fb002f
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_format_bptc.c
@@ -0,0 +1,26 @@
+#include "u_format.h"
+#include "u_format_bptc.h"
+
+#define fake(format) \
+void \
+util_format_##format##_fetch_rgba_8unorm(uint8_t *dst, const uint8_t *src,
unsigned i, unsigned j) {assert(0);} \
+\
+void \
+util_format_##format##_unpack_rgba_8unorm(uint8_t *dst_row, unsigned
dst_stride, const uint8_t *src_row, unsigned src_stride, unsigned width,
[Mesa-dev] [PATCH 4/4] nvc0: add BPTC format support
Signed-off-by: Ilia Mirkin --- Confusing, but nvc0_formats.c #includes nv50_formats.c. src/gallium/drivers/nouveau/nv50/nv50_formats.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c b/src/gallium/drivers/nouveau/nv50/nv50_formats.c index ff33654..df55623 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_formats.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_formats.c @@ -62,12 +62,14 @@ # define U_IC U_IB # define U_TCV U_TBV # define U_ICV U_IBV +# define U_t U_T # define U_tV U_TV #else # define U_TC U_TR # define U_IC U_IR # define U_TCV U_TRV # define U_ICV U_IRV +# define U_t 0 # define U_tV U_V #endif @@ -285,6 +287,11 @@ const struct nv50_format nv50_format_table[PIPE_FORMAT_COUNT] = C4B(LATC2_UNORM, NONE, C0, C0, C0, C1, UNORM, RGTC2, T), C4B(LATC2_SNORM, NONE, C0, C0, C0, C1, SNORM, RGTC2, T), + C4B(BPTC_RGBA_UNORM, NONE, C0, C1, C2, C3, UNORM, BPTC, t), + C4B(BPTC_SRGBA_UNORM, NONE, C0, C1, C2, C3, UNORM, BPTC, t), + F3B(BPTC_RGB_FLOAT, NONE, C0, C1, C2, xx, FLOAT, BPTC_FLOAT, t), + F3B(BPTC_RGB_UFLOAT, NONE, C0, C1, C2, xx, FLOAT, BPTC_UFLOAT, t), + C4A(R32G32B32A32_FLOAT, RGBA32_FLOAT, C0, C1, C2, C3, FLOAT, 32_32_32_32, IBV, 0), C4A(R32G32B32A32_UNORM, NONE, C0, C1, C2, C3, UNORM, 32_32_32_32, TV, 0), -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] softpipe, llvmpipe: mark BPTC formats as unsupported
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/llvmpipe/lp_screen.c | 5 +
src/gallium/drivers/softpipe/sp_screen.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 3218eb6..6d580c4 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -408,6 +408,11 @@ llvmpipe_is_format_supported( struct pipe_screen *_screen,
}
}
+ if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ /* Software decoding is not hooked up. */
+ return FALSE;
+ }
+
if (format_desc->layout == UTIL_FORMAT_LAYOUT_S3TC) {
return util_format_s3tc_enabled;
}
diff --git a/src/gallium/drivers/softpipe/sp_screen.c
b/src/gallium/drivers/softpipe/sp_screen.c
index 13f4723..7be39d4 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -322,6 +322,11 @@ softpipe_is_format_supported( struct pipe_screen *screen,
return FALSE;
}
+ if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ /* Software decoding is not hooked up. */
+ return FALSE;
+ }
+
/*
* All other operations (sampling, transfer, etc).
*/
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] mesa/st: add BPTC formats, expose ARB_texture_compression_bptc
Signed-off-by: Ilia Mirkin
---
This trivially depends on Neil's patches which add the mesa/core bits.
src/mesa/state_tracker/st_extensions.c | 6 ++
src/mesa/state_tracker/st_format.c | 36 ++
2 files changed, 42 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index aa59fbf..7297ffb 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -491,6 +491,12 @@ void st_init_extensions(struct st_context *st)
PIPE_FORMAT_DXT3_RGBA,
PIPE_FORMAT_DXT5_RGBA } },
+ { { o(ARB_texture_compression_bptc) },
+{ PIPE_FORMAT_BPTC_RGBA_UNORM,
+ PIPE_FORMAT_BPTC_SRGBA_UNORM,
+ PIPE_FORMAT_BPTC_RGB_FLOAT,
+ PIPE_FORMAT_BPTC_RGB_UFLOAT } },
+
{ { o(EXT_texture_shared_exponent) },
{ PIPE_FORMAT_R9G9B9E5_FLOAT } },
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 409079b..4ce5d43 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -326,6 +326,15 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat)
case MESA_FORMAT_ETC1_RGB8:
return PIPE_FORMAT_ETC1_RGB8;
+ case MESA_FORMAT_BPTC_RGBA_UNORM:
+ return PIPE_FORMAT_BPTC_RGBA_UNORM;
+ case MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM:
+ return PIPE_FORMAT_BPTC_SRGBA_UNORM;
+ case MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT:
+ return PIPE_FORMAT_BPTC_RGB_FLOAT;
+ case MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT:
+ return PIPE_FORMAT_BPTC_RGB_UFLOAT;
+
/* signed normalized formats */
case MESA_FORMAT_R_SNORM8:
return PIPE_FORMAT_R8_SNORM;
@@ -685,6 +694,15 @@ st_pipe_format_to_mesa_format(enum pipe_format format)
case PIPE_FORMAT_ETC1_RGB8:
return MESA_FORMAT_ETC1_RGB8;
+ case PIPE_FORMAT_BPTC_RGBA_UNORM:
+ return MESA_FORMAT_BPTC_RGBA_UNORM;
+ case PIPE_FORMAT_BPTC_SRGBA_UNORM:
+ return MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM;
+ case PIPE_FORMAT_BPTC_RGB_FLOAT:
+ return MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT;
+ case PIPE_FORMAT_BPTC_RGB_UFLOAT:
+ return MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT;
+
/* signed normalized formats */
case PIPE_FORMAT_R8_SNORM:
return MESA_FORMAT_R_SNORM8;
@@ -1238,6 +1256,24 @@ static const struct format_mapping format_map[] = {
{ PIPE_FORMAT_ETC1_RGB8, 0 }
},
+ /* BPTC */
+ {
+ { GL_COMPRESSED_RGBA_BPTC_UNORM, 0 },
+ { PIPE_FORMAT_BPTC_RGBA_UNORM, 0 },
+ },
+ {
+ { GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM, 0 },
+ { PIPE_FORMAT_BPTC_SRGBA_UNORM, 0 },
+ },
+ {
+ { GL_COMPRESSED_RGB_BPTC_SIGNED_FLOAT, 0 },
+ { PIPE_FORMAT_BPTC_RGB_FLOAT, 0 },
+ },
+ {
+ { GL_COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT, 0 },
+ { PIPE_FORMAT_BPTC_RGB_UFLOAT, 0 },
+ },
+
/* signed/unsigned integer formats.
*/
{
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add an accelerated version of F_TO_I for x86_64
On Mon, Jul 21, 2014 at 5:29 PM, Matt Turner wrote:
> On Mon, Jul 21, 2014 at 5:16 PM, Jason Ekstrand
> wrote:
> > Signed-off-by: Jason Ekstrand
> > ---
> > src/mesa/main/imports.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> > index af780b2..5d6486b 100644
> > --- a/src/mesa/main/imports.h
> > +++ b/src/mesa/main/imports.h
> > @@ -285,6 +285,10 @@ static inline int F_TO_I(float f)
> > int r;
> > __asm__ ("fistpl %0" : "=m" (r) : "t" (f) : "st");
> > return r;
> > +#elif defined(USE_X86_64_ASM) && defined(__GNUC__)
> > + int r;
> > + __asm__ ("cvtss2si %1, %0" : "=r" (r) : "xm" (f));
>
> "xm"? I think you just want "x"
>
No, this is needed because it uses an SSE register.
>
> Also "=&r" since it's written without ever being read.
>
Reading the GCC docs, I don't see how earlyclobber is appropreate. Would
you care to explain your reasoning further?
>
> > + return r;
> > #elif defined(USE_X86_ASM) && defined(_MSC_VER)
> > int r;
> > _asm {
> > --
>
> Remove the ' XXX We could use an x86-64/SSE2 version here.' comment
> above the function too.
>
Good catch
>
> I'd expect some data about this change. Performance data would be
> nice, but I'd take just the output of `size` on i965_dri.so.
>
Sure, I've got a little performance data if you'd like.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs/GL3.txt: put ARB_compute_shader back to undone.
It's still "started" though -- there's a partial implementation in master. On Wed, Jul 23, 2014 at 10:30 AM, Dave Airlie wrote: > It appears Paul isn't working on this. > > Signed-off-by: Dave Airlie > --- > docs/GL3.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/docs/GL3.txt b/docs/GL3.txt > index 0f37da4..9a80fca 100644 > --- a/docs/GL3.txt > +++ b/docs/GL3.txt > @@ -157,7 +157,7 @@ GL 4.3: >GL_ARB_arrays_of_arrays started (Timothy) >GL_ARB_ES3_compatibility DONE (i965) >GL_ARB_clear_buffer_object DONE (all drivers) > - GL_ARB_compute_shaderstarted (Paul Berry) > + GL_ARB_compute_shadernot started >GL_ARB_copy_imagenot started >GL_KHR_debug DONE (all drivers) >GL_ARB_explicit_uniform_location DONE (all drivers > that support GLSL) > -- > 1.9.3 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] Add texstore functions for BPTC-compressed textures
On Tue, Jul 22, 2014 at 3:09 PM, Neil Roberts wrote:
> This adds compressors for all four of the BPTC compressed-texture formats. For
> the RGB and SRGB normalized BPTC textures it works by first compressing each
> 4x4 block using the existing DXT3 compressor and then converting it to a BPTC
> block. The BPTC block loses one bit of information on the green component of
> the endpoints and one bit from the alpha values.
>
> The compressor for the two half-float formats is written from scratch and
> takes a very simple approach. It always uses mode 3 of the BPTC format and
> picks the two endpoints by dividing the texels into those which have more or
> less than the average luminance of the block and then calculating an average
> color of the texels within each division.
>
> The first approach using DXT3 gives much better results but neither is really
> very good. However it's probably not really sensible to try to use BPTC
> compression at runtime because for example with the Nvidia compression tool it
> can take in the order of an hour to compress a full-screen image. With that in
> mind I don't think it's worth having a proper compressor in Mesa and this
> approach gives reasonable results for a usage that is basically a corner case.
> ---
> src/mesa/main/texcompress_bptc.c | 533
> +++
> src/mesa/main/texcompress_bptc.h | 10 +
> src/mesa/main/texstore.c | 10 +
> 3 files changed, 553 insertions(+)
>
> diff --git a/src/mesa/main/texcompress_bptc.c
> b/src/mesa/main/texcompress_bptc.c
> index 0068975..48271793 100644
> --- a/src/mesa/main/texcompress_bptc.c
> +++ b/src/mesa/main/texcompress_bptc.c
> @@ -956,3 +963,529 @@ _mesa_get_bptc_fetch_func(mesa_format format)
[...]
> +_mesa_texstore_bptc_rgb_unsigned_float(TEXSTORE_PARAMS)
> +{
> + ASSERT(dstFormat == MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT);
> +
> + return texstore_bptc_rgb_float(ctx, dims, baseInternalFormat,
> + dstFormat, dstRowStride, dstSlices,
> + srcWidth, srcHeight, srcDepth,
> + srcFormat, srcType,
> + srcAddr, srcPacking,
> + false /* unsigned */);
> +}
> +
Pretty minor, but thought I'd report it:
Applying: Add texstore functions for BPTC-compressed textures
/home/ilia/src/mesa/.git/rebase-apply/patch:561: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Also, don't forget to prefix your patches with things like mesa: or
whatever's appropriate.
Cheers,
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs/GL3.txt: put ARB_compute_shader back to undone.
It appears Paul isn't working on this. Signed-off-by: Dave Airlie --- docs/GL3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index 0f37da4..9a80fca 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -157,7 +157,7 @@ GL 4.3: GL_ARB_arrays_of_arrays started (Timothy) GL_ARB_ES3_compatibility DONE (i965) GL_ARB_clear_buffer_object DONE (all drivers) - GL_ARB_compute_shaderstarted (Paul Berry) + GL_ARB_compute_shadernot started GL_ARB_copy_imagenot started GL_KHR_debug DONE (all drivers) GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/17] i965: Rename array_spacing_lod0 to non_mip_arrays
On Tue, Jul 22, 2014 at 11:14 AM, Pohjolainen, Topi
wrote:
> On Fri, Jul 18, 2014 at 02:16:47PM -0700, Jordan Justen wrote:
>> Generalize the name array_spacing_lod0 to non_mip_arrays. Previously
>> it was only used in certain cases where only a single mip-level was
>> used.
>>
>> For gen6 we will use non-mipmapped array spacing, but with multiple
>> mip levels. This is needed because gen6 hiz and stencil only support a
>> single mip-level.
>>
>> PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
>> to [DevSNB]:
>> "The separate stencil buffer does not support mip mapping, thus the
>> storage for LODs other than LOD 0 is not needed."
>>
>> PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
>> "[DevSNB]: The hierarchical depth buffer does not support the LOD
>> field, it is assumed by hardware to be zero. A separate
>> hierarachical depth buffer is required for each LOD used, and the
>> corresponding buffer???s state delivered to hardware each time a new
>> depth buffer state with modified LOD is delivered."
>>
>> Signed-off-by: Jordan Justen
>
> I know I complained about the name in the first place, and I'm not too happy
> about this either. The structure is still a "mip array" as it supports
> multiple layers for multiple levels (I think the original as array of
> miptrees and this new layout as miptree of arrays). I don't have anything
> better to suggest and hence I'm fine with this or even dropping this patch.
I don't want leave it as array_spacing_lod0, since that has a specific
hardware meaning, and we are extending the use of the field.
What about something like this?
enum miptree_array_layout {
/* Each array slice contains all miplevels packed together.
*
* Gen hardware usually wants miptrees
* configured this way.
*/
ALL_LOD_IN_EACH_SLICE,
/* Each LOD contains all slices of that LOD packed together.
*
* Multisampled surfaces use this for array_spacing_lod0.
*
* Gen6 uses this for separate stencil and hiz.
*/
ALL_SLICES_AT_EACH_LOD,
};
So, code might look like:
if (mt->array_layout == ALL_SLICES_AT_EACH_LOD)
-Jordan
> I had some minor comments for the rest of the series and something to be
> clarified in patch 16 but 12-17 are:
>
> Reviewed-by: Topi Pohjolainen
>
>> ---
>> src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 +-
>> src/mesa/drivers/dri/i965/brw_blorp.h | 2 +-
>> src/mesa/drivers/dri/i965/brw_tex_layout.c| 2 +-
>> src/mesa/drivers/dri/i965/gen7_blorp.cpp | 2 +-
>> src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 6 +++---
>> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +++---
>> src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
>> 7 files changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> b/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> index b57721c..c5ed84a 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
>> @@ -82,7 +82,7 @@ brw_blorp_surface_info::set(struct brw_context *brw,
>> {
>> brw_blorp_mip_info::set(mt, level, layer);
>> this->num_samples = mt->num_samples;
>> - this->array_spacing_lod0 = mt->array_spacing_lod0;
>> + this->non_mip_arrays = mt->non_mip_arrays;
>> this->map_stencil_as_y_tiled = false;
>> this->msaa_layout = mt->msaa_layout;
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h
>> b/src/mesa/drivers/dri/i965/brw_blorp.h
>> index 683f09e..0b360c5 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp.h
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.h
>> @@ -153,7 +153,7 @@ public:
>> /* Setting this flag indicates that the surface should be set up in
>> * ARYSPC_LOD0 mode. Ignored prior to Gen7.
>> */
>> - bool array_spacing_lod0;
>> + bool non_mip_arrays;
>>
>> /**
>> * Format that should be used when setting up the surface state for this
>> diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
>> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
>> index 76044b2..9e2720b 100644
>> --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
>> +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
>> @@ -241,7 +241,7 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
>>
>> h0 = ALIGN(mt->physical_height0, mt->align_h);
>> h1 = ALIGN(minify(mt->physical_height0, 1), mt->align_h);
>> - if (mt->array_spacing_lod0)
>> + if (mt->non_mip_arrays)
>>mt->qpitch = h0;
>> else
>>mt->qpitch = (h0 + h1 + (brw->gen >= 7 ? 12 : 11) * mt->align_h);
>> diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
>> b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
>> index 0ad570b..c33cfeb 100644
>> --- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
>> +++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
>> @@ -169,7 +169,7 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
>> if (surface->mt->align_w == 8)
>>surf[0] |= GEN7_SURFACE_HALIGN_8;
>>
>> - if
[Mesa-dev] [PATCH 7/7] mesa/shaderimage.c: fix inconsistent sign warning
Signed-off-by: Alon Levy
---
src/mesa/main/shaderimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
index d1e752d..298ede2 100644
--- a/src/mesa/main/shaderimage.c
+++ b/src/mesa/main/shaderimage.c
@@ -383,7 +383,7 @@ validate_image_unit(struct gl_context *ctx, struct
gl_image_unit *u)
void
_mesa_validate_image_units(struct gl_context *ctx)
{
- int i;
+ unsigned i;
for (i = 0; i < ctx->Const.MaxImageUnits; ++i) {
struct gl_image_unit *u = &ctx->ImageUnits[i];
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] wgl: stw_pixelformat_get_info: correct type for index variable
Signed-off-by: Alon Levy
---
src/gallium/state_trackers/wgl/stw_pixelformat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/wgl/stw_pixelformat.c
b/src/gallium/state_trackers/wgl/stw_pixelformat.c
index 1ef302d..7e5561b 100644
--- a/src/gallium/state_trackers/wgl/stw_pixelformat.c
+++ b/src/gallium/state_trackers/wgl/stw_pixelformat.c
@@ -297,7 +297,7 @@ stw_pixelformat_get_extended_count( void )
const struct stw_pixelformat_info *
stw_pixelformat_get_info( int iPixelFormat )
{
- int index;
+ unsigned index;
if (iPixelFormat <= 0) {
return NULL;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] glsl: fix inconsistent struct/class warning in vs12
Remove incorrect struct prefix, ir_variable is a class Signed-off-by: Alon Levy --- src/glsl/opt_dead_builtin_varyings.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/opt_dead_builtin_varyings.cpp b/src/glsl/opt_dead_builtin_varyings.cpp index c2a306e..f98a21f 100644 --- a/src/glsl/opt_dead_builtin_varyings.cpp +++ b/src/glsl/opt_dead_builtin_varyings.cpp @@ -334,7 +334,7 @@ public: } void prepare_array(exec_list *ir, - struct ir_variable **new_var, + ir_variable **new_var, int max_elements, unsigned start_location, const char *var_name, const char *mode_str, unsigned usage, unsigned external_usage) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] gallium/u_math.h: don't redefine INFINITY and NAN in VS2013
Under VS2013 compiler that is distinguished by _MSC_VER of 1800 those two
are already defined, use the SDK definition.
Another option would have been to undef and use the definitions here - I'm
not sure which is better.
---
This removes warnings, this patch is not actually required to build.
src/gallium/auxiliary/util/u_math.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index ec03e4e..60995d7 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -136,10 +136,10 @@ roundf(float x)
{
return x >= 0.0f ? floorf(x + 0.5f) : ceilf(x - 0.5f);
}
-#endif
#define INFINITY (DBL_MAX + DBL_MAX)
#define NAN (INFINITY - INFINITY)
+#endif
#endif /* _MSC_VER */
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] gallium/u_debug_flush.c: fix build error for vs12
use util_snprintf that is already defined in other systems by u_string.h
to as snprintf, so to not change behavior in other systems.
Signed-off-by: Alon Levy
---
src/gallium/auxiliary/util/u_debug_flush.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug_flush.c
b/src/gallium/auxiliary/util/u_debug_flush.c
index 9cf70db..fdb248c 100644
--- a/src/gallium/auxiliary/util/u_debug_flush.c
+++ b/src/gallium/auxiliary/util/u_debug_flush.c
@@ -46,6 +46,7 @@
#include "util/u_hash_table.h"
#include "util/u_double_list.h"
#include "util/u_inlines.h"
+#include "util/u_string.h"
#include "os/os_thread.h"
#include
@@ -320,8 +321,8 @@ debug_flush_might_flush_cb(void *key, void *value, void
*data)
const char *reason = (const char *) data;
char message[80];
- snprintf(message, sizeof(message),
-"%s referenced mapped buffer detected.", reason);
+ util_snprintf(message, sizeof(message),
+ "%s referenced mapped buffer detected.", reason);
pipe_mutex_lock(fbuf->mutex);
if (fbuf->mapped_sync) {
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/7] vs12 cleanup patches
Hi, These patches include some actual fixes for building target libgl-gdi with scons, and some warning removal (there are a ton left I didn't pursue - mostly truncation warnings and sign warnings). Not related to the patchset, but important for anyone building libgl-gdi (i.e. opengl32.dll) scons 2.3.2 seems broken wrt def files, I opened issue http://scons.tigris.org/issues/show_bug.cgi?id=2966 and used the patch included there to successfully build the dll. Alon Alon Levy (7): gallium/u_math.h: don't redefine INFINITY and NAN in VS2013 glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead gallium/u_debug_flush.c: fix build error for vs12 u_math.h: fix 64 to 32 bit truncation warning wgl: stw_pixelformat_get_info: correct type for index variable glsl: fix inconsistent struct/class warning in vs12 mesa/shaderimage.c: fix inconsistent sign warning src/gallium/auxiliary/util/u_debug_flush.c | 5 +++-- src/gallium/auxiliary/util/u_math.h | 4 ++-- src/gallium/state_trackers/wgl/stw_pixelformat.c | 2 +- src/glsl/glsl_parser.yy | 4 src/glsl/opt_dead_builtin_varyings.cpp | 2 +- src/mesa/main/shaderimage.c | 2 +- 6 files changed, 12 insertions(+), 7 deletions(-) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] u_math.h: fix 64 to 32 bit truncation warning
Signed-off-by: Alon Levy --- This file is common so this warning comes up a lot. src/gallium/auxiliary/util/u_math.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h index 60995d7..7c1ac4a 100644 --- a/src/gallium/auxiliary/util/u_math.h +++ b/src/gallium/auxiliary/util/u_math.h @@ -760,7 +760,7 @@ util_bswap64(uint64_t n) #if defined(HAVE___BUILTIN_BSWAP64) return __builtin_bswap64(n); #else - return ((uint64_t)util_bswap32(n) << 32) | + return ((uint64_t)util_bswap32((uint32_t)n) << 32) | util_bswap32((n >> 32)); #endif } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
Signed-off-by: Alon Levy --- src/glsl/glsl_parser.yy | 4 1 file changed, 4 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index faaf438..25370cd 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -26,6 +26,10 @@ #include #include +#ifdef _MSC_VER <= 1800 +#define strcasecmp _stricmp +#endif + #include "ast.h" #include "glsl_parser_extras.h" #include "glsl_types.h" -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
On Tue, Jul 22, 2014 at 11:43 AM, Dylan Baker wrote:
> GBM_DRIVERS_PATH is not documented, and only used to set the location of
> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
> is documented.
>
> Generally this split leads to confusion as to why gbm doesn't work.
>
> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
>
> v2: - Use GBM_DRIVERS_PATH as a fallback
>
> Signed-off-by: Dylan Baker
> ---
> src/gbm/backends/dri/gbm_dri.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index 347bc99..3e4851c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
> char *get_extensions_name;
>
> search_paths = NULL;
> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
> if (geteuid() == getuid()) {
> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
> - search_paths = getenv("GBM_DRIVERS_PATH");
> + search_paths = getenv("LIBGL_DRIVERS_PATH");
> +
> + /* fallback path for compatability, GBM_DRIVERS_PATH should be
compatibility
I don't even know that we ever need to drop GBM_DRIVERS_PATH, it's
pretty harmless. Either way,
Reviewed-by: Kristian Høgsberg
> + * dropped eventually
> + */
> + if (search_paths == NULL) {
> + search_paths = getenv("GBM_DRIVERS_PATH");
> + }
> }
> if (search_paths == NULL)
>search_paths = DEFAULT_DRIVER_DIR;
> --
> 2.0.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
Reviewed-by: Jordan Justen
On Tue, Jul 22, 2014 at 11:43 AM, Dylan Baker wrote:
> GBM_DRIVERS_PATH is not documented, and only used to set the location of
> gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
> is documented.
>
> Generally this split leads to confusion as to why gbm doesn't work.
>
> This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
> GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
>
> v2: - Use GBM_DRIVERS_PATH as a fallback
>
> Signed-off-by: Dylan Baker
> ---
> src/gbm/backends/dri/gbm_dri.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
> index 347bc99..3e4851c 100644
> --- a/src/gbm/backends/dri/gbm_dri.c
> +++ b/src/gbm/backends/dri/gbm_dri.c
> @@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
> char *get_extensions_name;
>
> search_paths = NULL;
> + /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
> if (geteuid() == getuid()) {
> - /* don't allow setuid apps to use GBM_DRIVERS_PATH */
> - search_paths = getenv("GBM_DRIVERS_PATH");
> + search_paths = getenv("LIBGL_DRIVERS_PATH");
> +
> + /* fallback path for compatability, GBM_DRIVERS_PATH should be
> + * dropped eventually
> + */
> + if (search_paths == NULL) {
> + search_paths = getenv("GBM_DRIVERS_PATH");
> + }
> }
> if (search_paths == NULL)
>search_paths = DEFAULT_DRIVER_DIR;
> --
> 2.0.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/6] i965: Enable the GL_ARB_texture_compression_bptc extension
On Tue, Jul 22, 2014 at 3:10 PM, Neil Roberts wrote:
> Enables the BPTC extension on Gen>=7 and adds the necessary format mappings to
> get the right surface type value.
> ---
> src/mesa/drivers/dri/i965/brw_surface_formats.c | 5 +
> src/mesa/drivers/dri/i965/intel_extensions.c| 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
> b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> index 41f4221..974f2df 100644
> --- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
> +++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> @@ -487,6 +487,11 @@ brw_format_for_mesa_format(mesa_format mesa_format)
>[MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1] =
> BRW_SURFACEFORMAT_ETC2_RGB8_PTA,
>[MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1] =
> BRW_SURFACEFORMAT_ETC2_SRGB8_PTA,
>
> + [MESA_FORMAT_BPTC_RGBA_UNORM] = BRW_SURFACEFORMAT_BC7_UNORM,
> + [MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM] = BRW_SURFACEFORMAT_BC7_UNORM_SRGB,
> + [MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT] = BRW_SURFACEFORMAT_BC6H_SF16,
> + [MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT] = BRW_SURFACEFORMAT_BC6H_UF16,
> +
>[MESA_FORMAT_A_SNORM8] = 0,
>[MESA_FORMAT_L_SNORM8] = 0,
>[MESA_FORMAT_L8A8_SNORM] = 0,
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index fe40068..13f2205 100644
> --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> @@ -301,6 +301,8 @@ intelInitExtensions(struct gl_context *ctx)
> ctx->Extensions.ARB_viewport_array = true;
> ctx->Extensions.AMD_vertex_shader_viewport_index = true;
>}
> +
> + ctx->Extensions.ARB_texture_compression_bptc = true;
Might want to make a mention in docs/GL3.txt and
docs/relnotes/10.3.html (opinions differ on whether that should go
into the same commit or a separate commit, do whatever you prefer).
> }
>
> if (brw->gen >= 8) {
> --
> 1.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] Add texstore functions for BPTC-compressed textures
This adds compressors for all four of the BPTC compressed-texture formats. For
the RGB and SRGB normalized BPTC textures it works by first compressing each
4x4 block using the existing DXT3 compressor and then converting it to a BPTC
block. The BPTC block loses one bit of information on the green component of
the endpoints and one bit from the alpha values.
The compressor for the two half-float formats is written from scratch and
takes a very simple approach. It always uses mode 3 of the BPTC format and
picks the two endpoints by dividing the texels into those which have more or
less than the average luminance of the block and then calculating an average
color of the texels within each division.
The first approach using DXT3 gives much better results but neither is really
very good. However it's probably not really sensible to try to use BPTC
compression at runtime because for example with the Nvidia compression tool it
can take in the order of an hour to compress a full-screen image. With that in
mind I don't think it's worth having a proper compressor in Mesa and this
approach gives reasonable results for a usage that is basically a corner case.
---
src/mesa/main/texcompress_bptc.c | 533 +++
src/mesa/main/texcompress_bptc.h | 10 +
src/mesa/main/texstore.c | 10 +
3 files changed, 553 insertions(+)
diff --git a/src/mesa/main/texcompress_bptc.c b/src/mesa/main/texcompress_bptc.c
index 0068975..48271793 100644
--- a/src/mesa/main/texcompress_bptc.c
+++ b/src/mesa/main/texcompress_bptc.c
@@ -29,6 +29,7 @@
#include
#include "texcompress.h"
#include "texcompress_bptc.h"
+#include "texcompress_s3tc.h"
#include "texstore.h"
#include "macros.h"
#include "format_unpack.h"
@@ -69,6 +70,12 @@ struct bptc_float_mode {
struct bptc_float_bitfield bitfields[24];
};
+struct bit_writer {
+ uint8_t buf;
+ int pos;
+ uint8_t *dst;
+};
+
static const struct bptc_unorm_mode
bptc_unorm_modes[] = {
/* 0 */ { 3, 4, false, false, 4, 0, true, false, 3, 0 },
@@ -956,3 +963,529 @@ _mesa_get_bptc_fetch_func(mesa_format format)
return NULL;
}
}
+
+static int
+get_alpha_index(int min, int max, int value)
+{
+ if (min == max)
+ return 0;
+ else
+ return (value - min) * 7 / (max - min);
+}
+
+static void
+extract_rgb(uint16_t src, uint8_t *dst)
+{
+ dst[0] = src >> 11;
+ /* We need to lose one bit of the green component */
+ dst[1] = ((src >> 6) & 0x1f);
+ dst[2] = src & 0x1f;
+}
+
+static void
+write_bits(struct bit_writer *writer, int n_bits, int value)
+{
+ do {
+ if (n_bits + writer->pos >= 8) {
+ *(writer->dst++) = writer->buf | (value << writer->pos);
+ writer->buf = 0;
+ value >>= (8 - writer->pos);
+ n_bits -= (8 - writer->pos);
+ writer->pos = 0;
+ } else {
+ writer->buf |= value << writer->pos;
+ writer->pos += n_bits;
+ break;
+ }
+ } while (n_bits > 0);
+}
+
+static void
+convert_dxt3_to_mode4(const uint8_t *src,
+ uint8_t *dst)
+{
+ uint8_t rgb[2][4];
+ uint8_t t[4];
+ uint8_t alpha0, alpha1;
+ bool invert_rgb_indices;
+ bool invert_alpha_indices;
+ int min_alpha = 0xf, max_alpha = 0x0, alpha;
+ struct bit_writer writer;
+ int endpoint, component;
+ int i, value;
+
+ extract_rgb(src[8] | (src[9] << 8), rgb[0]);
+ extract_rgb(src[10] | (src[11] << 8), rgb[1]);
+
+ /* In DXT3 the order of the endpoints is irrelevant. However in BPTC the
+* order needs to be set so that the anchor index (in this case index 0)
+* has the most-significant bit set to zero. Therefore if the high bit of
+* the first index is set then we need to swap the order. Because the order
+* of the DXT indices is different, the most-significant bit effectively
+* comes from bit 0 */
+ if (src[12] & 1) {
+ memcpy(t, rgb[0], sizeof t);
+ memcpy(rgb[0], rgb[1], sizeof t);
+ memcpy(rgb[1], t, sizeof t);
+ invert_rgb_indices = true;
+ } else {
+ invert_rgb_indices = false;
+ }
+
+ /* We need to truncate the 4 alpha bits to 3 so in order to get the best
+* use of the bits we can calculate the range of alpha values used and set
+* the endpoints to that */
+ for (i = 0; i < BLOCK_SIZE * BLOCK_SIZE / 2; i++) {
+ alpha = src[i] & 0x0f;
+ if (alpha < min_alpha)
+ min_alpha = alpha;
+ if (alpha > max_alpha)
+ max_alpha = alpha;
+ alpha = src[i] >> 4;
+ if (alpha < min_alpha)
+ min_alpha = alpha;
+ if (alpha > max_alpha)
+ max_alpha = alpha;
+ }
+
+ /* We may also need to swap the alpha values to make the anchor index have
+* a zero most-significant bit */
+ if (get_alpha_index(min_alpha, max_alpha, src[0] & 0x0f) & 0x04) {
+ alpha0 = max_alpha;
+ alpha1 = min_alpha;
+ invert_alpha_indices = true;
+ } else {
+ alpha0 = min_alpha;
+ alpha1 = max_alpha;
+ invert_alpha_indice
[Mesa-dev] [PATCH 5/6] i965: Enable the GL_ARB_texture_compression_bptc extension
Enables the BPTC extension on Gen>=7 and adds the necessary format mappings to
get the right surface type value.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 5 +
src/mesa/drivers/dri/i965/intel_extensions.c| 2 ++
2 files changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 41f4221..974f2df 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -487,6 +487,11 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1] =
BRW_SURFACEFORMAT_ETC2_RGB8_PTA,
[MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1] =
BRW_SURFACEFORMAT_ETC2_SRGB8_PTA,
+ [MESA_FORMAT_BPTC_RGBA_UNORM] = BRW_SURFACEFORMAT_BC7_UNORM,
+ [MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM] = BRW_SURFACEFORMAT_BC7_UNORM_SRGB,
+ [MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT] = BRW_SURFACEFORMAT_BC6H_SF16,
+ [MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT] = BRW_SURFACEFORMAT_BC6H_UF16,
+
[MESA_FORMAT_A_SNORM8] = 0,
[MESA_FORMAT_L_SNORM8] = 0,
[MESA_FORMAT_L8A8_SNORM] = 0,
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index fe40068..13f2205 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -301,6 +301,8 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.ARB_viewport_array = true;
ctx->Extensions.AMD_vertex_shader_viewport_index = true;
}
+
+ ctx->Extensions.ARB_texture_compression_bptc = true;
}
if (brw->gen >= 8) {
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] Add the GL_ARB_texture_compression_bptc extension
This adds a boolean in the gl_extensions struct for
GL_ARB_texture_compression_bptc as well as an entry in extension_table.
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 92e3f0d..2db27f4 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -155,6 +155,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_texture_buffer_object_rgb32",
o(ARB_texture_buffer_object_rgb32), GLC,2009 },
{ "GL_ARB_texture_buffer_range",
o(ARB_texture_buffer_range),GLC,2012 },
{ "GL_ARB_texture_compression", o(dummy_true),
GLL,2000 },
+ { "GL_ARB_texture_compression_bptc",
o(ARB_texture_compression_bptc),GL, 2010 },
{ "GL_ARB_texture_compression_rgtc",
o(ARB_texture_compression_rgtc),GL, 2004 },
{ "GL_ARB_texture_cube_map",o(ARB_texture_cube_map),
GLL,1999 },
{ "GL_ARB_texture_cube_map_array",
o(ARB_texture_cube_map_array), GL, 2009 },
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 91d9172..c63561f 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3570,6 +3570,7 @@ struct gl_extensions
GLboolean ARB_texture_buffer_object;
GLboolean ARB_texture_buffer_object_rgb32;
GLboolean ARB_texture_buffer_range;
+ GLboolean ARB_texture_compression_bptc;
GLboolean ARB_texture_compression_rgtc;
GLboolean ARB_texture_cube_map;
GLboolean ARB_texture_cube_map_array;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] Add the format enums for BPTC-compressed images
This adds the following four Mesa image format enums which correspond to the
four BPTC compressed texture formats:
MESA_FORMAT_BPTC_RGBA_UNORM
MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM
MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT
MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT
It also updates the format information functions to handle these and the
corresponding GL enums.
---
src/mesa/main/formats.c | 46
src/mesa/main/formats.h | 6 ++
src/mesa/main/glformats.c| 10 ++
src/mesa/main/texcompress.c | 24 +++
src/mesa/main/texformat.c| 8
src/mesa/main/teximage.c | 14 ++
src/mesa/swrast/s_texfetch.c | 24 +++
7 files changed, 132 insertions(+)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index 1f20a9a..d72f26c 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -1804,6 +1804,42 @@ static struct gl_format_info
format_info[MESA_FORMAT_COUNT] =
0, 0, 0, 0, 0,
4, 4, 8 /* 8 bytes per 4x4 block */
},
+ {
+ MESA_FORMAT_BPTC_RGBA_UNORM,
+ "MESA_FORMAT_BPTC_RGBA_UNORM",
+ GL_RGBA,
+ GL_UNSIGNED_NORMALIZED,
+ 4, 4, 4, 4,
+ 0, 0, 0, 0, 0,
+ 4, 4, 16 /* 16 bytes per 4x4 block */
+ },
+ {
+ MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM,
+ "MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM",
+ GL_RGBA,
+ GL_UNSIGNED_NORMALIZED,
+ 4, 4, 4, 4,
+ 0, 0, 0, 0, 0,
+ 4, 4, 16 /* 16 bytes per 4x4 block */
+ },
+ {
+ MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT,
+ "MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT",
+ GL_RGB,
+ GL_FLOAT,
+ 4, 4, 4, 0,
+ 0, 0, 0, 0, 0,
+ 4, 4, 16 /* 16 bytes per 4x4 block */
+ },
+ {
+ MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT,
+ "MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT",
+ GL_RGB,
+ GL_FLOAT,
+ 4, 4, 4, 0,
+ 0, 0, 0, 0, 0,
+ 4, 4, 16 /* 16 bytes per 4x4 block */
+ }
};
@@ -2660,6 +2696,10 @@ _mesa_format_to_type_and_comps(mesa_format format,
case MESA_FORMAT_ETC2_SIGNED_RG11_EAC:
case MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1:
case MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1:
+ case MESA_FORMAT_BPTC_RGBA_UNORM:
+ case MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM:
+ case MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT:
+ case MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT:
/* XXX generate error instead? */
*datatype = GL_UNSIGNED_BYTE;
*comps = 0;
@@ -3216,6 +3256,12 @@ _mesa_format_matches_format_and_type(mesa_format
mesa_format,
case MESA_FORMAT_RGBA_DXT5:
return GL_FALSE;
+ case MESA_FORMAT_BPTC_RGBA_UNORM:
+ case MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM:
+ case MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT:
+ case MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT:
+ return GL_FALSE;
+
case MESA_FORMAT_RGBA_FLOAT32:
return format == GL_RGBA && type == GL_FLOAT && !swapBytes;
case MESA_FORMAT_RGBA_FLOAT16:
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index dc50bc8..0ad8378 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -403,6 +403,12 @@ typedef enum
MESA_FORMAT_ETC2_RGB8_PUNCHTHROUGH_ALPHA1,
MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1,
+ /* BPTC compressed formats */
+ MESA_FORMAT_BPTC_RGBA_UNORM,
+ MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM,
+ MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT,
+ MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT,
+
MESA_FORMAT_COUNT
} mesa_format;
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 304d452..7341b80 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -623,6 +623,10 @@ _mesa_is_color_format(GLenum format)
case GL_COMPRESSED_SIGNED_RG11_EAC:
case GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2:
case GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2:
+ case GL_COMPRESSED_RGBA_BPTC_UNORM:
+ case GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM:
+ case GL_COMPRESSED_RGB_BPTC_SIGNED_FLOAT:
+ case GL_COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT:
/* generic integer formats */
case GL_RED_INTEGER_EXT:
case GL_GREEN_INTEGER_EXT:
@@ -876,6 +880,12 @@ _mesa_is_compressed_format(struct gl_context *ctx, GLenum
format)
case GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2:
case GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2:
return _mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility;
+ case GL_COMPRESSED_RGBA_BPTC_UNORM:
+ case GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM:
+ case GL_COMPRESSED_RGB_BPTC_SIGNED_FLOAT:
+ case GL_COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT:
+ return _mesa_is_desktop_gl(ctx) &&
+ ctx->Extensions.ARB_texture_compression_bptc;
case GL_PALETTE4_RGB8_OES:
case GL_PALETTE4_RGBA8_OES:
case GL_PALETTE4_R5_G6_B5_OES:
diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index 9dbfe9f..b708b49 100644
--- a/src/mesa/m
[Mesa-dev] [PATCH 0/6] Add support for BPTC texture compression
Here's a first attempt at a patch series to implement BPTC texture compression in the i965 driver on Gen>=7. Getting it to work on the hardware is pretty trivial as it's just a case of adding some new Mesa format enums and then plugging them together with the right Intel surface type. However GL requires that you are able to get the library to compress textures on the fly so we need a compressor too. I think for BPTC it doesn't really make much sense to actually use this because it takes a very long time to search the entire space and compress an image properly. For example the NVidia compressor takes in the order of an hour for a full-screen image. Instead I've just done the minimal work needed to get something that gives vaguely passable results. For the two normalized formats I've just made it first compress each block with the existing DXT3 compressor and then convert the block to mode 4 of BPTC. This ends up being worse than just using DXT3 directly because it will lose a bit from the green component of the endpoints and each alpha index will be 3 bits instead of 4, but it looks ok. For the two half-float formats I've written a custom compressor which just has a very simple algorithm and always uses mode 3. I've also written software texel fetch functions for all of the formats. I guess in theory we don't need these because we should just be able to use the hardware to decompress if someone calls glGetTexImage. However Mesa has a static assert to require a texel fetch function and it seemed like a good way to learn more about the format so I wrote the functions anyway. It also means we can enable the extension on the software rasterizer. I've written a Piglit test for the decompressor with the normalized formats. I also tested the half-float decompressor using NVidia's sample texture which tries every mode. It would be good to make a Piglit test that does this as well. - Neil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/6] swrast: Enable GL_ARB_texture_compression_bptc
Enables BPTC texture compression on the software rasterizer. --- src/mesa/main/extensions.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c index 2db27f4..154c1cd 100644 --- a/src/mesa/main/extensions.c +++ b/src/mesa/main/extensions.c @@ -448,6 +448,7 @@ _mesa_enable_sw_extensions(struct gl_context *ctx) ctx->Extensions.ARB_point_sprite = GL_TRUE; ctx->Extensions.ARB_shadow = GL_TRUE; ctx->Extensions.ARB_texture_border_clamp = GL_TRUE; + ctx->Extensions.ARB_texture_compression_bptc = GL_TRUE; ctx->Extensions.ARB_texture_cube_map = GL_TRUE; ctx->Extensions.ARB_texture_env_combine = GL_TRUE; ctx->Extensions.ARB_texture_env_crossbar = GL_TRUE; -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] Add texel fetch functions for BPTC-compressed textures
Adds functions to fetch from any of the four BPTC-compressed formats.
---
src/mesa/Makefile.sources| 1 +
src/mesa/main/texcompress.c | 6 +
src/mesa/main/texcompress_bptc.c | 958 +++
src/mesa/main/texcompress_bptc.h | 34 ++
4 files changed, 999 insertions(+)
create mode 100644 src/mesa/main/texcompress_bptc.c
create mode 100644 src/mesa/main/texcompress_bptc.h
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index f4904fb..52b9891 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -93,6 +93,7 @@ MAIN_FILES = \
$(SRCDIR)main/stencil.c \
$(SRCDIR)main/syncobj.c \
$(SRCDIR)main/texcompress.c \
+ $(SRCDIR)main/texcompress_bptc.c \
$(SRCDIR)main/texcompress_cpal.c \
$(SRCDIR)main/texcompress_rgtc.c \
$(SRCDIR)main/texcompress_s3tc.c \
diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index b708b49..d3fff1d 100644
--- a/src/mesa/main/texcompress.c
+++ b/src/mesa/main/texcompress.c
@@ -42,6 +42,7 @@
#include "texcompress_rgtc.h"
#include "texcompress_s3tc.h"
#include "texcompress_etc.h"
+#include "texcompress_bptc.h"
/**
@@ -610,6 +611,11 @@ _mesa_get_compressed_fetch_func(mesa_format format)
return _mesa_get_compressed_rgtc_func(format);
case MESA_FORMAT_ETC1_RGB8:
return _mesa_get_etc_fetch_func(format);
+ case MESA_FORMAT_BPTC_RGBA_UNORM:
+ case MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM:
+ case MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT:
+ case MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT:
+ return _mesa_get_bptc_fetch_func(format);
default:
return NULL;
}
diff --git a/src/mesa/main/texcompress_bptc.c b/src/mesa/main/texcompress_bptc.c
new file mode 100644
index 000..0068975
--- /dev/null
+++ b/src/mesa/main/texcompress_bptc.c
@@ -0,0 +1,958 @@
+/*
+ * Copyright (C) 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * \file texcompress_bptc.c
+ * GL_ARB_texture_compression_bptc support.
+ */
+
+#include
+#include "texcompress.h"
+#include "texcompress_bptc.h"
+#include "texstore.h"
+#include "macros.h"
+#include "format_unpack.h"
+#include "image.h"
+
+#define BLOCK_SIZE 4
+#define N_PARTITIONS 64
+#define BLOCK_BYTES 16
+
+struct bptc_unorm_mode {
+ int n_subsets;
+ int n_partition_bits;
+ bool has_rotation_bits;
+ bool has_index_selection_bit;
+ int n_color_bits;
+ int n_alpha_bits;
+ bool has_endpoint_pbits;
+ bool has_shared_pbits;
+ int n_index_bits;
+ int n_secondary_index_bits;
+};
+
+struct bptc_float_bitfield {
+ int8_t endpoint;
+ uint8_t component;
+ uint8_t offset;
+ uint8_t n_bits;
+ bool reverse;
+};
+
+struct bptc_float_mode {
+ bool reserved;
+ bool transformed_endpoints;
+ int n_partition_bits;
+ int n_endpoint_bits;
+ int n_index_bits;
+ int n_delta_bits[3];
+ struct bptc_float_bitfield bitfields[24];
+};
+
+static const struct bptc_unorm_mode
+bptc_unorm_modes[] = {
+ /* 0 */ { 3, 4, false, false, 4, 0, true, false, 3, 0 },
+ /* 1 */ { 2, 6, false, false, 6, 0, false, true, 3, 0 },
+ /* 2 */ { 3, 6, false, false, 5, 0, false, false, 2, 0 },
+ /* 3 */ { 2, 6, false, false, 7, 0, true, false, 2, 0 },
+ /* 4 */ { 1, 0, true, true, 5, 6, false, false, 2, 3 },
+ /* 5 */ { 1, 0, true, false, 7, 8, false, false, 2, 2 },
+ /* 6 */ { 1, 0, false, false, 7, 7, true, false, 4, 0 },
+ /* 7 */ { 2, 6, false, false, 5, 5, true, false, 2, 0 }
+};
+
+static const struct bptc_float_mode
+bptc_float_modes[] = {
+ /* 00 */
+ { false, true, 5, 10, 3, { 5, 5, 5 },
+ { { 2, 1, 4, 1, false }, { 2, 2, 4, 1, false }, { 3, 2, 4, 1, false },
+ { 0, 0, 0, 10, false }, { 0, 1, 0, 10, false }, { 0, 2, 0, 10, false },
+ { 1, 0, 0, 5, false }, { 3, 1, 4, 1, false }, { 2, 1, 0, 4, false },
+ { 1, 1, 0, 5, false }, { 3, 2, 0, 1, fals
[Mesa-dev] [PATCH v2] gbm: Replace GBM_DRIVERS_PATH with LIBGL_DRIVERS_PATH
GBM_DRIVERS_PATH is not documented, and only used to set the location of
gbm drivers, while LIBGL_DRIVERS_PATH is used for everything else, and
is documented.
Generally this split leads to confusion as to why gbm doesn't work.
This patch makes LIBGL_DRIVERS_PATH the main variable, but uses
GBM_DRIVERS_PATH as a fallback if LIBGL_DRIVERS_PATH is NULL.
v2: - Use GBM_DRIVERS_PATH as a fallback
Signed-off-by: Dylan Baker
---
src/gbm/backends/dri/gbm_dri.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 347bc99..3e4851c 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -211,9 +211,16 @@ dri_load_driver(struct gbm_dri_device *dri)
char *get_extensions_name;
search_paths = NULL;
+ /* don't allow setuid apps to use LIBGL_DRIVERS_PATH */
if (geteuid() == getuid()) {
- /* don't allow setuid apps to use GBM_DRIVERS_PATH */
- search_paths = getenv("GBM_DRIVERS_PATH");
+ search_paths = getenv("LIBGL_DRIVERS_PATH");
+
+ /* fallback path for compatability, GBM_DRIVERS_PATH should be
+ * dropped eventually
+ */
+ if (search_paths == NULL) {
+ search_paths = getenv("GBM_DRIVERS_PATH");
+ }
}
if (search_paths == NULL)
search_paths = DEFAULT_DRIVER_DIR;
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v4 0/3] Software rendering in EGL-DRM
On 22/07/14 18:41, Giovanni Campagna wrote:
> On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov
> wrote:
>> On 21/07/14 17:02, Giovanni Campagna wrote:
>>> On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov
>>> wrote:
Giovanni can you test the series that I've not butchered anything else
during
the rebase ?
>>>
>>> Oh hey, sorry I missed the bit that I was expected to test the patches.
>>> Unfortunately, something indeed got lost: the logic to choose the
>>> kms_swrast driver in preference to the swrast one.
>>>
>>> In my patches, I had:
>>>
>>> static int
>>> dri_screen_create_sw(struct gbm_dri_device *dri)
>>> {
>>>int ret;
>>>
>>>ret = dri_screen_create_dri2(dri, "kms_swrast");
>>>if (ret == 0)
>>> return ret;
>>>
>>>return dri_screen_create_swrast(dri);
>>> }
>>>
>>> That would take the place of dri_screen_create_swrast in the
>>> dri_device_create() call site.
>>> With your patches, the kms_swrast driver is effectively never loaded.
>>>
>> Am I day-dreaming, or is this the same as your initial concern as stated here
>> [0] ? If so I believe that this should be fully addressed with the follow-up
>> revision of patches 1 [1] & 2 [2].
>>
>> Perhaps the updated patches never made it to your inbox :'(
>
> My bad, I was testing the old patch.
> Nevertheless, the new patch is not working either: after the
> megadrivers work, the new kms_swrast_dri is trying to load ilo when
> run on an intel card with GBM_ALWAYS_SOFTWARE, because
> loader_get_pci_from_fd() returns i965. This fails because ilo is not
> compiled in (and even if ilo was compiled, it would fail because ilo
> does not support my GM45).
> Then weston crashes using the swrast driver, because at that point the
> kms_swrast driver was already partially loaded and extensions bound
> (so it takes a mixture of swrast and dri2 paths).
>
> On intel, this problem can be worked around by removing the
> LOADER_GALLIUM from the i965 entry in the pci_id_driver_map table, but
> on nouveau/r600g/radeonsi it would result on a working GBM, HW
> accelerated despite the environment variable. I believe the
> _getDriverExtension_kms_swrast() function should return a different
> extension table for kms_swrast (one that references a InitScreen that
> always initializes a kms_swrast screen).
Good catch! The series targets qxl and similar devices so I haven't considered
the case when someone forces kms_swrast on a HWaccel capable setup.
> Additionally, it's probably a bad idea to fallback to kms_swrast
> unconditionally, because kms_swrast will fail spectacularly on x11 or
> wayland.
>
Adding a separate InitScreen hook which explicitly calls
pipe_kms_swrast_create_screen() sounds like the most sensible thing IMHO.
Huge thanks for the help.
-Emil
P.S. I dare you to test the branch on your intel setup for a normal gbm/egl
workload. Hint, dri_screen_create() will succeed, yet dri_screen_create_sw()
will be executed as well :)
> OTOH, once loaded the driver works fine.
>
> Giovanni
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/17] i965: Rename array_spacing_lod0 to non_mip_arrays
On Fri, Jul 18, 2014 at 02:16:47PM -0700, Jordan Justen wrote:
> Generalize the name array_spacing_lod0 to non_mip_arrays. Previously
> it was only used in certain cases where only a single mip-level was
> used.
>
> For gen6 we will use non-mipmapped array spacing, but with multiple
> mip levels. This is needed because gen6 hiz and stencil only support a
> single mip-level.
>
> PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
> to [DevSNB]:
> "The separate stencil buffer does not support mip mapping, thus the
> storage for LODs other than LOD 0 is not needed."
>
> PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
> "[DevSNB]: The hierarchical depth buffer does not support the LOD
> field, it is assumed by hardware to be zero. A separate
> hierarachical depth buffer is required for each LOD used, and the
> corresponding buffer???s state delivered to hardware each time a new
> depth buffer state with modified LOD is delivered."
>
> Signed-off-by: Jordan Justen
I know I complained about the name in the first place, and I'm not too happy
about this either. The structure is still a "mip array" as it supports
multiple layers for multiple levels (I think the original as array of
miptrees and this new layout as miptree of arrays). I don't have anything
better to suggest and hence I'm fine with this or even dropping this patch.
I had some minor comments for the rest of the series and something to be
clarified in patch 16 but 12-17 are:
Reviewed-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 +-
> src/mesa/drivers/dri/i965/brw_blorp.h | 2 +-
> src/mesa/drivers/dri/i965/brw_tex_layout.c| 2 +-
> src/mesa/drivers/dri/i965/gen7_blorp.cpp | 2 +-
> src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 6 +++---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +++---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
> 7 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp
> b/src/mesa/drivers/dri/i965/brw_blorp.cpp
> index b57721c..c5ed84a 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
> @@ -82,7 +82,7 @@ brw_blorp_surface_info::set(struct brw_context *brw,
> {
> brw_blorp_mip_info::set(mt, level, layer);
> this->num_samples = mt->num_samples;
> - this->array_spacing_lod0 = mt->array_spacing_lod0;
> + this->non_mip_arrays = mt->non_mip_arrays;
> this->map_stencil_as_y_tiled = false;
> this->msaa_layout = mt->msaa_layout;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h
> b/src/mesa/drivers/dri/i965/brw_blorp.h
> index 683f09e..0b360c5 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.h
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.h
> @@ -153,7 +153,7 @@ public:
> /* Setting this flag indicates that the surface should be set up in
> * ARYSPC_LOD0 mode. Ignored prior to Gen7.
> */
> - bool array_spacing_lod0;
> + bool non_mip_arrays;
>
> /**
> * Format that should be used when setting up the surface state for this
> diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> index 76044b2..9e2720b 100644
> --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> @@ -241,7 +241,7 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
>
> h0 = ALIGN(mt->physical_height0, mt->align_h);
> h1 = ALIGN(minify(mt->physical_height0, 1), mt->align_h);
> - if (mt->array_spacing_lod0)
> + if (mt->non_mip_arrays)
>mt->qpitch = h0;
> else
>mt->qpitch = (h0 + h1 + (brw->gen >= 7 ? 12 : 11) * mt->align_h);
> diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> index 0ad570b..c33cfeb 100644
> --- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
> @@ -169,7 +169,7 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
> if (surface->mt->align_w == 8)
>surf[0] |= GEN7_SURFACE_HALIGN_8;
>
> - if (surface->array_spacing_lod0)
> + if (surface->non_mip_arrays)
>surf[0] |= GEN7_SURFACE_ARYSPC_LOD0;
> else
>surf[0] |= GEN7_SURFACE_ARYSPC_FULL;
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> index 01120af..5d068d4 100644
> --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> @@ -315,7 +315,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
> uint32_t effective_depth = (tObj->Immutable && tObj->Target !=
> GL_TEXTURE_3D)
>? tObj->NumLayers : mt->logical_depth0;
>
> - if (mt->array_spacing_lod0)
> + if (mt->non_mip_arrays)
>surf[0] |= GEN7_SURFACE_ARYSPC_LOD0;
>
> surf[1] = mt->bo->offset64 + mt->off
Re: [Mesa-dev] [PATCH 17/17] i965/gen6: Force non_mip_arrays for separate stencil/hiz
On Fri, Jul 18, 2014 at 02:16:52PM -0700, Jordan Justen wrote:
> For gen6 we will use non-mipmapped array spacing, but with multiple
> mip levels. This is needed because gen6 hiz and separate stencil only
> support a single mip-level.
>
> PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
> to [DevSNB]:
> "The separate stencil buffer does not support mip mapping, thus the
> storage for LODs other than LOD 0 is not needed."
>
> We still allocate storage for the other stencil mip-levels within a
> single texture, but each mip-level will use non-mip-array spacing.
>
> PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
> "[DevSNB]: The hierarchical depth buffer does not support the LOD
> field, it is assumed by hardware to be zero. A separate
> hierarachical depth buffer is required for each LOD used, and the
> corresponding buffer???s state delivered to hardware each time a new
> depth buffer state with modified LOD is delivered."
>
> We allocate storage for the other hiz mip-levels within a single
> texture, but each mip-level will use non-mip-array spacing.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 2a5afab..67cf515 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -331,8 +331,10 @@ intel_miptree_create_layout(struct brw_context *brw,
>}
> }
>
> - /* non_mip_arrays is only used for non-IMS MSAA surfaces. TODO: can we
> -* use it elsewhere?
> + /* non_mip_arrays is only used for:
> +* - non-IMS MSAA surfaces
> +* - gen6 separate stencil
> +* - gen6 hiz
> */
> switch (mt->msaa_layout) {
> case INTEL_MSAA_LAYOUT_NONE:
> @@ -358,6 +360,7 @@ intel_miptree_create_layout(struct brw_context *brw,
> _mesa_get_format_base_format(format) == GL_DEPTH_STENCIL &&
> (brw->must_use_separate_stencil ||
> (brw->has_separate_stencil && brw_is_hiz_depth_format(brw, format {
> + bool force_non_mip_arrays = brw->gen == 6;
const
>mt->stencil_mt = intel_miptree_create(brw,
> mt->target,
> MESA_FORMAT_S_UINT8,
> @@ -369,7 +372,7 @@ intel_miptree_create_layout(struct brw_context *brw,
> true,
> num_samples,
> INTEL_MIPTREE_TILING_ANY,
> -false);
> +force_non_mip_arrays);
>if (!mt->stencil_mt) {
>intel_miptree_release(&mt);
>return NULL;
> @@ -1386,6 +1389,7 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
> struct intel_mipmap_tree *mt)
> {
> assert(mt->hiz_mt == NULL);
> + bool force_non_mip_arrays = brw->gen == 6;
const
> mt->hiz_mt = intel_miptree_create(brw,
> mt->target,
> mt->format,
> @@ -1397,7 +1401,7 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
> true,
> mt->num_samples,
> INTEL_MIPTREE_TILING_ANY,
> - false);
> + force_non_mip_arrays);
>
> if (!mt->hiz_mt)
>return false;
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/17] i965/gen6: Force tile alignment for each stencil/hiz LOD
On Fri, Jul 18, 2014 at 02:16:50PM -0700, Jordan Justen wrote:
> Gen6 doesn't support multiple miplevels for hiz and stencil.
>
> Therefore, we must point to the LOD directly during rendering.
>
> But, we also have removed the tile offsets from normal depth surfaces,
> so we need to align each LOD to a tile boundary for hiz and stencil.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_tex_layout.c | 39
> +++---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> index 9d248cb..b6fed4d 100644
> --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> @@ -35,6 +35,7 @@
> #include "intel_mipmap_tree.h"
> #include "brw_context.h"
> #include "main/macros.h"
> +#include "main/glformats.h"
>
> #define FILE_DEBUG_FLAG DEBUG_MIPTREE
>
> @@ -318,9 +319,41 @@ void
> brw_miptree_layout(struct brw_context *brw, struct intel_mipmap_tree *mt)
> {
> bool multisampled = mt->num_samples > 1;
> - mt->align_w = intel_horizontal_texture_alignment_unit(brw, mt->format);
> - mt->align_h =
> - intel_vertical_texture_alignment_unit(brw, mt->format, multisampled);
> + bool gen6_hiz_or_stencil = false;
> +
> + if (brw->gen == 6 && mt->non_mip_arrays) {
> + GLenum base_format = _mesa_get_format_base_format(mt->format);
Minor nit, could be declared constant.
> + gen6_hiz_or_stencil = _mesa_is_depth_or_stencil_format(base_format);
> + }
> +
> + if (gen6_hiz_or_stencil) {
> + /* On gen6, we use non_mip_arrays for stencil/hiz because the hardware
> + * doesn't support multiple mip levels on stencil/hiz.
> + *
> + * PRM Vol 2, Part 1, 7.5.3 Hierarchical Depth Buffer:
> + * "The hierarchical depth buffer does not support the LOD field"
> + *
> + * PRM Vol 2, Part 1, 7.5.4.1 Separate Stencil Buffer:
> + * "The stencil depth buffer does not support the LOD field"
> + */
> + if (mt->format == MESA_FORMAT_S_UINT8) {
> + /* Stencil uses W tiling, so we force W tiling alignment for the
> + * non_mip_arrays based mip-levels.
> + */
> + mt->align_w = 64;
> + mt->align_h = 64;
> + } else {
> + /* Depth uses Y tiling, so we force need Y tiling alignment for the
> + * non_mip_arrays based mip-levels.
> + */
> + mt->align_w = 128 / mt->cpp;
> + mt->align_h = 32;
> + }
> + } else {
> + mt->align_w = intel_horizontal_texture_alignment_unit(brw, mt->format);
> + mt->align_h =
> + intel_vertical_texture_alignment_unit(brw, mt->format,
> multisampled);
> + }
>
> switch (mt->target) {
> case GL_TEXTURE_CUBE_MAP:
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/17] i965/gen6: Stencil/hiz needs an offset for LOD > 0
On Fri, Jul 18, 2014 at 02:16:51PM -0700, Jordan Justen wrote:
> Since gen6 separate stencil & hiz only supports LOD0, we need to
> program an offset to the LOD when emitting the separate stencil/hiz.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 10 +++-
> src/mesa/drivers/dri/i965/gen6_depth_state.c | 34
> ++--
> 2 files changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> index 5a56442..4dab569 100644
> --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> @@ -871,13 +871,21 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
> *brw,
> /* 3DSTATE_HIER_DEPTH_BUFFER */
> {
>struct intel_mipmap_tree *hiz_mt = params->depth.mt->hiz_mt;
> + uint32_t offset = 0;
> +
> + if (hiz_mt->non_mip_arrays) {
> + offset = intel_miptree_get_aligned_offset(hiz_mt,
> +
> hiz_mt->level[lod].level_x,
> +
> hiz_mt->level[lod].level_y,
> + false);
> + }
>
>BEGIN_BATCH(3);
>OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
>OUT_BATCH(hiz_mt->pitch - 1);
>OUT_RELOC(hiz_mt->bo,
> I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
> -0);
> +offset);
>ADVANCE_BATCH();
> }
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> index b58f970..fd37594 100644
> --- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> @@ -183,12 +183,22 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
>/* Emit hiz buffer. */
>if (hiz) {
> struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_mt;
> + uint32_t offset = 0;
> +
> + if (hiz_mt->non_mip_arrays) {
> +offset = intel_miptree_get_aligned_offset(
> +hiz_mt,
> +hiz_mt->level[lod].level_x,
> +hiz_mt->level[lod].level_y,
> +false);
> + }
> +
>BEGIN_BATCH(3);
>OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
>OUT_BATCH(hiz_mt->pitch - 1);
>OUT_RELOC(hiz_mt->bo,
> I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
> -0);
> +offset);
>ADVANCE_BATCH();
>} else {
>BEGIN_BATCH(3);
> @@ -200,6 +210,26 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
>
>/* Emit stencil buffer. */
>if (separate_stencil) {
> + uint32_t offset = 0;
> +
> + if (stencil_mt->non_mip_arrays) {
> +if (stencil_mt->format == MESA_FORMAT_S_UINT8) {
> + /* Note: we can't compute the stencil offset using
> +* intel_region_get_aligned_offset(), because stencil_region
> +* claims that the region is untiled even though it's W tiled.
> +*/
> + offset =
> + stencil_mt->level[lod].level_y * stencil_mt->pitch +
> + stencil_mt->level[lod].level_x * 64;
As we don't have the stencil using the normal mip-level organization (array
of miptrees) but rather mip-tree of arrays, all the individual slices have
x-offset zero, right?
> +} else {
> + offset = intel_miptree_get_aligned_offset(
> + stencil_mt,
> + stencil_mt->level[lod].level_x,
> + stencil_mt->level[lod].level_y,
> + false);
> +}
> + }
> +
>BEGIN_BATCH(3);
>OUT_BATCH((_3DSTATE_STENCIL_BUFFER << 16) | (3 - 2));
> /* The stencil buffer has quirky pitch requirements. From Vol 2a,
> @@ -210,7 +240,7 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
>OUT_BATCH(2 * stencil_mt->pitch - 1);
>OUT_RELOC(stencil_mt->bo,
> I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
> -0);
> +offset);
>ADVANCE_BATCH();
>} else {
>BEGIN_BATCH(3);
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/17] i965: Support non_mip_arrays for multiple miplevels
On Fri, Jul 18, 2014 at 02:16:49PM -0700, Jordan Justen wrote:
> Previously array spacing lod0 was only used with a single mip level.
> It indicated that no mip level spacing should be used between array
> slices.
>
> gen6 separate stencil & hiz only support LOD0, so we need to allocate
> the miptree similar to array spacing lod0, except we also need
> multiple mip levels.
>
> So, the miptree is allocated with tightly packed array slice spacing,
> but we still also pack the miplevels into the region similar to a
> normal multi mip level packing.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_tex_layout.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> index 9e2720b..9d248cb 100644
> --- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
> +++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
> @@ -203,6 +203,11 @@ brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
>if (mt->compressed)
>img_height /= mt->align_h;
>
> + if (mt->non_mip_arrays) {
> + /* Compact arrays with separated miplevels */
> + img_height *= depth;
I guess you have a tab here.
> + }
> +
>/* Because the images are packed better, the final offset
> * might not be the maximal one:
> */
> @@ -238,6 +243,7 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
>struct intel_mipmap_tree *mt)
> {
> int h0, h1;
> + unsigned height = mt->physical_height0;
>
> h0 = ALIGN(mt->physical_height0, mt->align_h);
> h1 = ALIGN(minify(mt->physical_height0, 1), mt->align_h);
> @@ -251,11 +257,22 @@ brw_miptree_layout_texture_array(struct brw_context
> *brw,
> brw_miptree_layout_2d(mt);
>
> for (unsigned level = mt->first_level; level <= mt->last_level; level++) {
> + unsigned img_height;
> + img_height = ALIGN(height, mt->align_h);
These could be on the same line.
> + if (mt->compressed)
> + img_height /= mt->align_h;
> +
>for (int q = 0; q < mt->physical_depth0; q++) {
> - intel_miptree_set_image_offset(mt, level, q, 0, q * physical_qpitch);
> + if (mt->non_mip_arrays) {
> +intel_miptree_set_image_offset(mt, level, q, 0, q * img_height);
> + } else {
> +intel_miptree_set_image_offset(mt, level, q, 0, q *
> physical_qpitch);
> + }
>}
> + height = minify(height, 1);
> }
> - mt->total_height = physical_qpitch * mt->physical_depth0;
> + if (!mt->non_mip_arrays)
> + mt->total_height = physical_qpitch * mt->physical_depth0;
>
> align_cube(mt);
> }
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/16] glsl: Correctly determine when the field of a UBO is row-major
On 07/21/2014 03:35 PM, Matt Turner wrote:
> On Mon, Jul 21, 2014 at 3:28 PM, Matt Turner wrote:
>> On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> Previously if a field of an block with an instance name was marked
>>> row-major (but block itself was not), we would think the field (and it's
>>> sub-fields) were column-major.
>>>
>>> Fixes gles3conform failures in:
>>>
>>> ES3-CTS.shaders.uniform_block.random.basic_types.7
>>> ES3-CTS.shaders.uniform_block.random.basic_types.9
>>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.1
>>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.3
>>> ES3-CTS.shaders.uniform_block.random.nested_structs.3
>>> ES3-CTS.shaders.uniform_block.random.nested_structs.5
>>> ES3-CTS.shaders.uniform_block.random.nested_structs.8
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.3
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.6
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.7
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.8
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.9
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.0
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.1
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.2
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.3
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.4
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.6
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.0
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.1
>>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.5
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.0
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.4
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.7
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.8
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.12
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.14
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.15
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.16
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.1
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.8
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.9
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.10
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.11
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.13
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.14
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.15
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.16
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.17
>>>
>>> Fixes gles3conform failures (caused by previous commits) in:
>>>
>>> ES3-CTS.shaders.uniform_block.random.basic_types.8
>>> ES3-CTS.shaders.uniform_block.random.basic_arrays.3
>>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.0
>>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.2
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.9
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.13
>>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.18
>>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.4
>>>
>>> Signed-off-by: Ian Romanick
>>> ---
>>> src/glsl/lower_ubo_reference.cpp | 137
>>> ++-
>>> 1 file changed, 122 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/src/glsl/lower_ubo_reference.cpp
>>> b/src/glsl/lower_ubo_reference.cpp
>>> index 99bfe97..0ee4e8a 100644
>>> --- a/src/glsl/lower_ubo_reference.cpp
>>> +++ b/src/glsl/lower_ubo_reference.cpp
>>> @@ -40,6 +40,98 @@
>>>
>>> using namespace ir_builder;
>>>
>>> +/**
>>> + * Determine if a thing being dereferenced is row-major
>>> + *
>>> + * There is some trickery here.
>>> + *
>>> + * If the thing being dereferenced is a member of uniform block \b without
>>> an
>>> + * instance name, then the name of the \c ir_variable is the field name of
>>> an
>>> + * interface type. If this field is row-major, then the thing referenced
>>> is
>>> + * row-major.
>>> + *
>>> + * If the thing being dereferenced is a member of uniform block \b with an
>>> + * instance name, then the last dereference in the tree will be an
>>> + * \c ir_dereference_record. If that record field is row-major, then the
>>> + * thing referenced is row-major.
>>> + */
>>> +static bool
>>> +is_dereferenced_thing_row_major(const ir_dereference *deref)
>>> +{
>>> + bool matrix = false;
>>> + const ir_rvalue *ir = deref;
>>> +
>>> + while (true) {
>>> + if (ir->type->is_matrix()
>>> + || (ir->type->is_array() && ir->type->fields.array->i
Re: [Mesa-dev] [PATCH 15/16] glsl: Correctly determine when the field of a UBO is row-major
On 07/21/2014 03:28 PM, Matt Turner wrote:
> On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Previously if a field of an block with an instance name was marked
>> row-major (but block itself was not), we would think the field (and it's
>> sub-fields) were column-major.
>>
>> Fixes gles3conform failures in:
>>
>> ES3-CTS.shaders.uniform_block.random.basic_types.7
>> ES3-CTS.shaders.uniform_block.random.basic_types.9
>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.1
>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.3
>> ES3-CTS.shaders.uniform_block.random.nested_structs.3
>> ES3-CTS.shaders.uniform_block.random.nested_structs.5
>> ES3-CTS.shaders.uniform_block.random.nested_structs.8
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.3
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.6
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.7
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.8
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.9
>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.0
>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.1
>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.2
>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.3
>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.4
>> ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.6
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.0
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.1
>> ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.5
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.0
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.4
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.7
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.8
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.12
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.14
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.15
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.16
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.1
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.8
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.9
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.10
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.11
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.13
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.14
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.15
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.16
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.17
>>
>> Fixes gles3conform failures (caused by previous commits) in:
>>
>> ES3-CTS.shaders.uniform_block.random.basic_types.8
>> ES3-CTS.shaders.uniform_block.random.basic_arrays.3
>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.0
>> ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.2
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.9
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.13
>> ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.18
>> ES3-CTS.shaders.uniform_block.random.all_shared_buffer.4
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/glsl/lower_ubo_reference.cpp | 137
>> ++-
>> 1 file changed, 122 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/glsl/lower_ubo_reference.cpp
>> b/src/glsl/lower_ubo_reference.cpp
>> index 99bfe97..0ee4e8a 100644
>> --- a/src/glsl/lower_ubo_reference.cpp
>> +++ b/src/glsl/lower_ubo_reference.cpp
>> @@ -40,6 +40,98 @@
>>
>> using namespace ir_builder;
>>
>> +/**
>> + * Determine if a thing being dereferenced is row-major
>> + *
>> + * There is some trickery here.
>> + *
>> + * If the thing being dereferenced is a member of uniform block \b without
>> an
>> + * instance name, then the name of the \c ir_variable is the field name of
>> an
>> + * interface type. If this field is row-major, then the thing referenced is
>> + * row-major.
>> + *
>> + * If the thing being dereferenced is a member of uniform block \b with an
>> + * instance name, then the last dereference in the tree will be an
>> + * \c ir_dereference_record. If that record field is row-major, then the
>> + * thing referenced is row-major.
>> + */
>> +static bool
>> +is_dereferenced_thing_row_major(const ir_dereference *deref)
>> +{
>> + bool matrix = false;
>> + const ir_rvalue *ir = deref;
>> +
>> + while (true) {
>> + if (ir->type->is_matrix()
>> + || (ir->type->is_array() && ir->type->fields.array->is_matrix()))
>
> Use your new function here.
Something seems to have gone wrong. The last version of this code was
matrix = matrix || ir->type->is_matrix_
Re: [Mesa-dev] [PATCH 03/16] glsl: Use constant_expression_value instead of as_constant
On 07/21/2014 03:39 PM, Matt Turner wrote: > On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote: >> From: Ian Romanick >> >> Just a few lines earlier we may have wrapped the index expression with >> ir_unop_i2u expression. Whenever that happens, as_constant will return >> NULL, and that almost always happens. > > Are you saying that since we just passed array_index to i2u we know it > must be a constant? I can follow that much, but I don't see anything > that really makes sure this is a constant. The code tries really hard to just generate a constant offset for the UBO access. To implement this optimization, this code was assuming the array index would be an ir_constant if the value was constant... but it does this right after possibly wrapping the ir_constant with an ir_expression. This change just makes the optimization actually do what it's intending to do by use ::constant_expression_value instead of as_constant. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/7] util: Add PIPE_FORMAT_x8B8G8R8_SNORM formats
Am 22.07.2014 12:02, schrieb Richard Sandiford:
> This means that each RnGnBnxn format has a reversed counterpart,
> which is necessary for handling big-endian mesa<->gallium mappings.
> The associated UNORM and SRGB formats already exist.
>
> Signed-off-by: Richard Sandiford
> ---
> src/gallium/auxiliary/util/u_format.csv | 3 +++
> src/gallium/include/pipe/p_format.h | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_format.csv
> b/src/gallium/auxiliary/util/u_format.csv
> index d01dd06..5bca5e8 100644
> --- a/src/gallium/auxiliary/util/u_format.csv
> +++ b/src/gallium/auxiliary/util/u_format.csv
> @@ -387,3 +387,6 @@ PIPE_FORMAT_G8R8_UNORM, plain, 1, 1, un8 ,
> un8 , , , yx01, rgb
> PIPE_FORMAT_G8R8_SNORM, plain, 1, 1, sn8 , sn8 , , , yx01, rgb
> PIPE_FORMAT_G16R16_UNORM , plain, 1, 1, un16, un16, , , yx01, rgb
> PIPE_FORMAT_G16R16_SNORM , plain, 1, 1, sn16, sn16, , , yx01, rgb
> +
> +PIPE_FORMAT_A8B8G8R8_SNORM, plain, 1, 1, sn8 , sn8 , sn8 , sn8 ,
> wzyx, rgb
> +PIPE_FORMAT_X8B8G8R8_SNORM, plain, 1, 1, x8, sn8, sn8, sn8,
> wzy1, rgb
> diff --git a/src/gallium/include/pipe/p_format.h
> b/src/gallium/include/pipe/p_format.h
> index 1dba5b5..a0cdde3 100644
> --- a/src/gallium/include/pipe/p_format.h
> +++ b/src/gallium/include/pipe/p_format.h
> @@ -354,6 +354,9 @@ enum pipe_format {
> PIPE_FORMAT_G16R16_UNORM= 261,
> PIPE_FORMAT_G16R16_SNORM= 262,
>
> + PIPE_FORMAT_A8B8G8R8_SNORM = 263,
> + PIPE_FORMAT_X8B8G8R8_SNORM = 264,
> +
> PIPE_FORMAT_COUNT
> };
>
>
This change + 2/7 and 2/5, 3/5 from the other series change core gallium
definitions, thus they should be prefixed with gallium, not util, even
if there's some util change as well.
Other than that I think they look reasonable though I'm not really
qualified as I stayed out of the endianness discussions - always gives
me headaches thinking about it :-).
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Doubt about Streamed Vertex Buffer Write message descriptor in SandyBridge
On Tue, Jul 22, 2014 at 11:25 AM, Samuel Iglesias Gonsálvez wrote: > Hello, > > I have a doubt related to Streamed Vertex Buffer Write message and its > message descriptor in SandyBridge. > > Reading about Stream Output Primitives Written > (snb_ihd_os_vol2_part1.pdf, pag 175), it says the following: > > "Whenever a GS thread outputs a DataPort Streamed Vertex Buffer Write > (SVBWrite) message with the Increment Num Prims Written bit set, the > SO_NUM_PRIMS_WRITTEN register will be incremented." > > According to SNB's spec [0], all the bits in the SVBWrite message > descriptor are ignored and I have not found the definition of this bit > in the documentation. Maybe I'm running the wrong pdfgrep command :-/ > > After doing some Google searches, I found that in other doc [1] it's > mentioned the "Increment Num Prims Written" bit inside the SVBWrite > message descriptor is not ignored for SNB (at least, it doesn't say that > explicitly). > > Do you know where is the "Increment Num Prims Written" bit defined in > SNB's doc? Not 100% sure if this is what you're looking for, but take a look at https://01.org/linuxgraphics/sites/default/files/documentation/snb_ihd_os_vol4_part2.pdf Page 23, 2.4.3.1 - SONumPrimsWritten and/or Page 29 - 2.4.4.1 NumGSPrimsGenerated and perhaps some of the other fields in the FF_SYNC message. Or wait until someone who knows what they're talking about replies :) -ilia > > Thanks, > > Sam > > [0] snb_ihd_os_vol4_part1.pdf, "3.9.11 Streamed Vertex Buffer Write > [DevSNB]", page 260. > [1] http://www.x.org/docs/intel/HD/IHD_OS_Vol_4_Part1_BJS.pdf "5.10.10 > Streamed Vertex Buffer Write [Pre-DevIVB]", page 247. > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Doubt about Streamed Vertex Buffer Write message descriptor in SandyBridge
Hello, I have a doubt related to Streamed Vertex Buffer Write message and its message descriptor in SandyBridge. Reading about Stream Output Primitives Written (snb_ihd_os_vol2_part1.pdf, pag 175), it says the following: "Whenever a GS thread outputs a DataPort Streamed Vertex Buffer Write (SVBWrite) message with the Increment Num Prims Written bit set, the SO_NUM_PRIMS_WRITTEN register will be incremented." According to SNB's spec [0], all the bits in the SVBWrite message descriptor are ignored and I have not found the definition of this bit in the documentation. Maybe I'm running the wrong pdfgrep command :-/ After doing some Google searches, I found that in other doc [1] it's mentioned the "Increment Num Prims Written" bit inside the SVBWrite message descriptor is not ignored for SNB (at least, it doesn't say that explicitly). Do you know where is the "Increment Num Prims Written" bit defined in SNB's doc? Thanks, Sam [0] snb_ihd_os_vol4_part1.pdf, "3.9.11 Streamed Vertex Buffer Write [DevSNB]", page 260. [1] http://www.x.org/docs/intel/HD/IHD_OS_Vol_4_Part1_BJS.pdf "5.10.10 Streamed Vertex Buffer Write [Pre-DevIVB]", page 247. signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: Fix fallback iround handling of integral inputs
Am 22.07.2014 12:26, schrieb Richard Sandiford:
> Roland Scheidegger writes:
>> Am 21.07.2014 17:53, schrieb Richard Sandiford:
>>> lp_build_iround has a fallback case that tries to emulate a round-to-nearest
>>> float->int conversion by adding 0.5 and using a truncating fptosi. For odd
>>> numbers in the range [2^23, 2^24], which are already integral, this has
>>> the effect of adding 1 to the integer, since the result of adding 0.5 is
>>> exactly half way between two representable values and the tie goes to even.
>>> This includes the important special case of (float)0xff, which is the
>>> maximum depth in a z24s8 format. I.e. calling iround on (float)0xff
>>> gives 0x100 rather than 0xff when the fallback is used.
>>>
>>> This patch only uses the x+0.5 trick if the ulp of the input is fractional.
>>> This still doesn't give ties-to-even semantics, but that doesn't seem to
>>> matter much in practice.
>>>
>>> Signed-off-by: Richard Sandiford
>>> ---
>>> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 43
>>> ++---
>>> 1 file changed, 27 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>>> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>>> index 9ef8628..82ddb5a 100644
>>> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>>> @@ -2181,25 +2181,36 @@ lp_build_iround(struct lp_build_context *bld,
>>>res = lp_build_round_arch(bld, a, LP_BUILD_ROUND_NEAREST);
>>> }
>>> else {
>>> - LLVMValueRef half;
>>> + struct lp_type int_type = lp_int_type(type);
>>> + LLVMTypeRef vec_type = bld->vec_type;
>>> + unsigned mantissa = lp_mantissa(type);
>>> + unsigned expbits = type.width - mantissa - 1;
>>> + unsigned bias = (1 << (expbits - 1)) - 1;
>>> + LLVMValueRef mask = lp_build_const_int_vec(bld->gallivm, type,
>>> + (unsigned long long)1 << (type.width - 1));
>>> + /* Smallest value with an integral ulp */
>>> + LLVMValueRef abslimit = lp_build_const_int_vec(bld->gallivm, type,
>>> + (bias + mantissa) << mantissa);
>>> + LLVMValueRef half, sign, absa, fractulp;
>>>
>>>half = lp_build_const_vec(bld->gallivm, type, 0.5);
>>>
>>> - if (type.sign) {
>>> - LLVMTypeRef vec_type = bld->vec_type;
>>> - LLVMValueRef mask = lp_build_const_int_vec(bld->gallivm, type,
>>> -(unsigned long long)1 << (type.width -
>>> 1));
>>> - LLVMValueRef sign;
>>> -
>>> - /* get sign bit */
>>> - sign = LLVMBuildBitCast(builder, a, int_vec_type, "");
>>> - sign = LLVMBuildAnd(builder, sign, mask, "");
>>> -
>>> - /* sign * 0.5 */
>>> - half = LLVMBuildBitCast(builder, half, int_vec_type, "");
>>> - half = LLVMBuildOr(builder, sign, half, "");
>>> - half = LLVMBuildBitCast(builder, half, vec_type, "");
>>> - }
>>> + assert(type.sign);
>> You can't assert here. It is quite legal to have floats without sign
>> type - used to skip things like here when we know the input is positive.
>> There might not be all that many callers using such build contexts,
>> though some quick glance identified at least two
>> (lp_build_coord_repeat_npot_linear_int,
>> lp_build_clamped_float_to_unsigned_norm). Though I would have thought
>> the latter is where the bug you're seeing is coming from...
>
> Ah, sorry, I hadn't realised that sort of modification could happen.
> I just looked at the types that lp_bld_type.h created.
>
>> Also, I'm not a fan of making this more complex in general.
>> lp_build_itrunc is most often used for converting texture coords, or
>
> (lp_build_iround rather than lp_build_itrunc?)
Yes.
>
>> other stuff like srgb conversion, and none of these callers care about
>> this, so maybe should distinguish the cases.
>
> As an extra boolean argument? Yeah, I can try that, although I'll probably
> need help deciding what the right argument is for some cases. Or were you
> thinking of something else?
Yes that's what I was thinking. Or otherwise use a different function.
Both solutions are kind of ugly though admittedly.
>
>>> +
>>> + /* get sign bit */
>>> + sign = LLVMBuildBitCast(builder, a, int_vec_type, "");
>>> + sign = LLVMBuildAnd(builder, sign, mask, "");
>>> +
>>> + /* get "ulp is fractional" */
>>> + absa = lp_build_abs(bld, a);
>>> + absa = LLVMBuildBitCast(builder, absa, int_vec_type, "");
>>> + fractulp = lp_build_compare(bld->gallivm, int_type, PIPE_FUNC_LESS,
>>> absa, abslimit);
>>> +
>>> + /* (sign * 0.5) & intulp */
>>> + half = LLVMBuildBitCast(builder, half, int_vec_type, "");
>>> + half = LLVMBuildOr(builder, sign, half, "");
>>> + half = LLVMBuildAnd(builder, half, fractulp, "");
>>> + half = LLVMBuildBitCast(builder, half, vec_type, "");
>>>
>>>
[Mesa-dev] [Bug 79949] [DRI3] GTK+ Programs Not Updating Correctly
https://bugs.freedesktop.org/show_bug.cgi?id=79949 Alex Deucher changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 81551 *** -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79949] [DRI3] GTK+ Programs Not Updating Correctly
https://bugs.freedesktop.org/show_bug.cgi?id=79949 --- Comment #10 from Joseph Booker --- (In reply to comment #9) > This is the same as bug 81551 ... can you test Chris's patch and confirm > whether it works or not? This fixes it. No graphical problems scrolling in Firefox or gedit. [ 643.373] (II) intel(0): direct rendering: DRI2 DRI3 enabled mesa-10.2.4 + xf86-video-intel-2.99.912 with Chris's patch. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: Fix fallback iround handling of integral inputs
Roland Scheidegger writes:
> Am 21.07.2014 17:53, schrieb Richard Sandiford:
>> lp_build_iround has a fallback case that tries to emulate a round-to-nearest
>> float->int conversion by adding 0.5 and using a truncating fptosi. For odd
>> numbers in the range [2^23, 2^24], which are already integral, this has
>> the effect of adding 1 to the integer, since the result of adding 0.5 is
>> exactly half way between two representable values and the tie goes to even.
>> This includes the important special case of (float)0xff, which is the
>> maximum depth in a z24s8 format. I.e. calling iround on (float)0xff
>> gives 0x100 rather than 0xff when the fallback is used.
>>
>> This patch only uses the x+0.5 trick if the ulp of the input is fractional.
>> This still doesn't give ties-to-even semantics, but that doesn't seem to
>> matter much in practice.
>>
>> Signed-off-by: Richard Sandiford
>> ---
>> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 43
>> ++---
>> 1 file changed, 27 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> index 9ef8628..82ddb5a 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> @@ -2181,25 +2181,36 @@ lp_build_iround(struct lp_build_context *bld,
>>res = lp_build_round_arch(bld, a, LP_BUILD_ROUND_NEAREST);
>> }
>> else {
>> - LLVMValueRef half;
>> + struct lp_type int_type = lp_int_type(type);
>> + LLVMTypeRef vec_type = bld->vec_type;
>> + unsigned mantissa = lp_mantissa(type);
>> + unsigned expbits = type.width - mantissa - 1;
>> + unsigned bias = (1 << (expbits - 1)) - 1;
>> + LLVMValueRef mask = lp_build_const_int_vec(bld->gallivm, type,
>> + (unsigned long long)1 << (type.width - 1));
>> + /* Smallest value with an integral ulp */
>> + LLVMValueRef abslimit = lp_build_const_int_vec(bld->gallivm, type,
>> + (bias + mantissa) << mantissa);
>> + LLVMValueRef half, sign, absa, fractulp;
>>
>>half = lp_build_const_vec(bld->gallivm, type, 0.5);
>>
>> - if (type.sign) {
>> - LLVMTypeRef vec_type = bld->vec_type;
>> - LLVMValueRef mask = lp_build_const_int_vec(bld->gallivm, type,
>> -(unsigned long long)1 << (type.width -
>> 1));
>> - LLVMValueRef sign;
>> -
>> - /* get sign bit */
>> - sign = LLVMBuildBitCast(builder, a, int_vec_type, "");
>> - sign = LLVMBuildAnd(builder, sign, mask, "");
>> -
>> - /* sign * 0.5 */
>> - half = LLVMBuildBitCast(builder, half, int_vec_type, "");
>> - half = LLVMBuildOr(builder, sign, half, "");
>> - half = LLVMBuildBitCast(builder, half, vec_type, "");
>> - }
>> + assert(type.sign);
> You can't assert here. It is quite legal to have floats without sign
> type - used to skip things like here when we know the input is positive.
> There might not be all that many callers using such build contexts,
> though some quick glance identified at least two
> (lp_build_coord_repeat_npot_linear_int,
> lp_build_clamped_float_to_unsigned_norm). Though I would have thought
> the latter is where the bug you're seeing is coming from...
Ah, sorry, I hadn't realised that sort of modification could happen.
I just looked at the types that lp_bld_type.h created.
> Also, I'm not a fan of making this more complex in general.
> lp_build_itrunc is most often used for converting texture coords, or
(lp_build_iround rather than lp_build_itrunc?)
> other stuff like srgb conversion, and none of these callers care about
> this, so maybe should distinguish the cases.
As an extra boolean argument? Yeah, I can try that, although I'll probably
need help deciding what the right argument is for some cases. Or were you
thinking of something else?
>> +
>> + /* get sign bit */
>> + sign = LLVMBuildBitCast(builder, a, int_vec_type, "");
>> + sign = LLVMBuildAnd(builder, sign, mask, "");
>> +
>> + /* get "ulp is fractional" */
>> + absa = lp_build_abs(bld, a);
>> + absa = LLVMBuildBitCast(builder, absa, int_vec_type, "");
>> + fractulp = lp_build_compare(bld->gallivm, int_type, PIPE_FUNC_LESS,
>> absa, abslimit);
>> +
>> + /* (sign * 0.5) & intulp */
>> + half = LLVMBuildBitCast(builder, half, int_vec_type, "");
>> + half = LLVMBuildOr(builder, sign, half, "");
>> + half = LLVMBuildAnd(builder, half, fractulp, "");
>> + half = LLVMBuildBitCast(builder, half, vec_type, "");
>>
>>res = LLVMBuildFAdd(builder, a, half, "");
>> }
>>
>
> Though if the caller is lp_build_round, it actually seems not too
> complicated - the abs() from both will be the same, and the comparison
> could be made (nearly) the same too (lp_build_round and friends are
> using 2^24, th
Re: [Mesa-dev] [PATCH 11/17] i965/gen6 depth surface: program 3DSTATE_DEPTH_BUFFER to top of surface
On Fri, Jul 18, 2014 at 02:16:46PM -0700, Jordan Justen wrote:
> (bf25ee2 for gen6)
>
> Previously we would always find the 2D sub-surface of interest,
> and then program the surface to this location. Now we always
> program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
> To select the lod/slice, we utilize the lod & minimum array
> element fields.
>
> We also must disable brw_workaround_depthstencil_alignment for
> gen >= 6. Now the hardware will handle alignment when rendering
> to additional slices/LODs.
>
> Signed-off-by: Jordan Justen
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56127
> ---
> src/mesa/drivers/dri/i965/brw_misc_state.c | 4 +-
> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 71
> +---
> src/mesa/drivers/dri/i965/gen6_depth_state.c | 32 ++---
> 3 files changed, 49 insertions(+), 58 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
> b/src/mesa/drivers/dri/i965/brw_misc_state.c
> index 76e22bd..e3980fc 100644
> --- a/src/mesa/drivers/dri/i965/brw_misc_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
> @@ -261,10 +261,10 @@ brw_workaround_depthstencil_alignment(struct
> brw_context *brw,
> if (stencil_irb)
>brw->depthstencil.stencil_mt = get_stencil_miptree(stencil_irb);
>
> - /* Gen7+ doesn't require the workarounds, since we always program the
> + /* Gen6+ doesn't require the workarounds, since we always program the
> * surface state at the start of the whole surface.
> */
> - if (brw->gen >= 7)
> + if (brw->gen >= 6)
>return;
>
> /* Check if depth buffer is in depth/stencil format. If so, then it's
> only
> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> index dca6bfc..5a56442 100644
> --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> @@ -787,10 +787,6 @@ static void
> gen6_blorp_emit_depth_stencil_config(struct brw_context *brw,
> const brw_blorp_params *params)
> {
> - struct gl_context *ctx = &brw->ctx;
> - uint32_t draw_x = params->depth.x_offset;
> - uint32_t draw_y = params->depth.y_offset;
> - uint32_t tile_mask_x, tile_mask_y;
> uint32_t surfwidth, surfheight;
> uint32_t surftype;
> unsigned int depth = MAX2(params->depth.mt->logical_depth0, 1);
> @@ -814,12 +810,6 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
> *brw,
>break;
> }
>
> - brw_get_depthstencil_tile_masks(params->depth.mt,
> - params->depth.level,
> - params->depth.layer,
> - NULL,
> - &tile_mask_x, &tile_mask_y);
> -
> min_array_element = params->depth.layer;
>
> lod = params->depth.level - params->depth.mt->first_level;
> @@ -838,55 +828,42 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
> *brw,
>
> /* 3DSTATE_DEPTH_BUFFER */
> {
> - uint32_t tile_x = draw_x & tile_mask_x;
> - uint32_t tile_y = draw_y & tile_mask_y;
> - uint32_t offset =
> - intel_miptree_get_aligned_offset(params->depth.mt,
> - draw_x & ~tile_mask_x,
> - draw_y & ~tile_mask_y, false);
> -
> - /* According to the Sandy Bridge PRM, volume 2 part 1, pp326-327
> - * (3DSTATE_DEPTH_BUFFER dw5), in the documentation for "Depth
> - * Coordinate Offset X/Y":
> - *
> - * "The 3 LSBs of both offsets must be zero to ensure correct
> - * alignment"
> - *
> - * We have no guarantee that tile_x and tile_y are correctly aligned,
> - * since they are determined by the mipmap layout, which is only
> aligned
> - * to multiples of 4.
> - *
> - * So, to avoid hanging the GPU, just smash the low order 3 bits of
> - * tile_x and tile_y to 0. This is a temporary workaround until we
> come
> - * up with a better solution.
> - */
> - WARN_ONCE((tile_x & 7) || (tile_y & 7),
> -"Depth/stencil buffer needs alignment to 8-pixel
> boundaries.\n"
> -"Truncating offset, bad rendering may occur.\n");
> - tile_x &= ~7;
> - tile_y &= ~7;
> -
>intel_emit_post_sync_nonzero_flush(brw);
>intel_emit_depth_stall_flushes(brw);
>
>BEGIN_BATCH(7);
> + /* 3DSTATE_DEPTH_BUFFER dw0 */
>OUT_BATCH(_3DSTATE_DEPTH_BUFFER << 16 | (7 - 2));
> +
> + /* 3DSTATE_DEPTH_BUFFER dw1 */
>OUT_BATCH((params->depth.mt->pitch - 1) |
> params->depth_format << 18 |
> 1 << 21 | /* separate stencil enable */
> 1 << 22 | /* hiz enable */
> BRW_TILEWALK_YMAJOR << 26 |
> 1 << 27 | /* y-tiled */
> -BRW_SURFACE_2D << 29);
> +
[Mesa-dev] [PATCH v2 5/7] mesa: Fix _mesa_texstore_signed_rgb?8888 for big-endian.
MESA_FORMAT_x8y8z8w8 means a format in which "x" is the least
signficant byte and "w" is the most significant byte. Most
functions get that right, but the signed ones access the
bytes from an array rather than an integer, so they need
to take endianness into account. This isn't too onerous
since both orders are already handled.
Signed-off-by: Richard Sandiford
---
src/mesa/main/texstore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index ae52bd3..22fc1e2 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -2276,6 +2276,7 @@ static GLboolean
_mesa_texstore_signed_rgbx(TEXSTORE_PARAMS)
{
const GLenum baseFormat = _mesa_get_format_base_format(dstFormat);
+ const GLboolean littleEndian = _mesa_little_endian();
ASSERT(dstFormat == MESA_FORMAT_X8B8G8R8_SNORM ||
dstFormat == MESA_FORMAT_R8G8B8X8_SNORM);
@@ -2298,7 +2299,7 @@ _mesa_texstore_signed_rgbx(TEXSTORE_PARAMS)
GLbyte *dstRow = (GLbyte *) dstSlices[img];
for (row = 0; row < srcHeight; row++) {
GLbyte *dst = dstRow;
-if (dstFormat == MESA_FORMAT_X8B8G8R8_SNORM) {
+if ((dstFormat == MESA_FORMAT_X8B8G8R8_SNORM) == littleEndian) {
for (col = 0; col < srcWidth; col++) {
dst[3] = FLOAT_TO_BYTE_TEX(srcRow[RCOMP]);
dst[2] = FLOAT_TO_BYTE_TEX(srcRow[GCOMP]);
@@ -2336,6 +2337,7 @@ static GLboolean
_mesa_texstore_signed_rgba(TEXSTORE_PARAMS)
{
const GLenum baseFormat = _mesa_get_format_base_format(dstFormat);
+ const GLboolean littleEndian = _mesa_little_endian();
ASSERT(dstFormat == MESA_FORMAT_A8B8G8R8_SNORM ||
dstFormat == MESA_FORMAT_R8G8B8A8_SNORM);
@@ -2358,7 +2360,7 @@ _mesa_texstore_signed_rgba(TEXSTORE_PARAMS)
GLbyte *dstRow = (GLbyte *) dstSlices[img];
for (row = 0; row < srcHeight; row++) {
GLbyte *dst = dstRow;
-if (dstFormat == MESA_FORMAT_A8B8G8R8_SNORM) {
+if ((dstFormat == MESA_FORMAT_A8B8G8R8_SNORM) == littleEndian) {
for (col = 0; col < srcWidth; col++) {
dst[3] = FLOAT_TO_BYTE_TEX(srcRow[RCOMP]);
dst[2] = FLOAT_TO_BYTE_TEX(srcRow[GCOMP]);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/7] mesa: Fix alpha component in unpack_R8G8B8X8_SRGB.
The function was using the "X" component as the alpha channel, rather than setting alpha to 1.0. Signed-off-by: Richard Sandiford --- src/mesa/main/format_unpack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c index ae14478..fddb067 100644 --- a/src/mesa/main/format_unpack.c +++ b/src/mesa/main/format_unpack.c @@ -2154,7 +2154,7 @@ unpack_R8G8B8X8_SRGB(const void *src, GLfloat dst[][4], GLuint n) dst[i][RCOMP] = _mesa_nonlinear_to_linear( (s[i] ) & 0xff ); dst[i][GCOMP] = _mesa_nonlinear_to_linear( (s[i] >> 8) & 0xff ); dst[i][BCOMP] = _mesa_nonlinear_to_linear( (s[i] >> 16) & 0xff ); - dst[i][ACOMP] = UBYTE_TO_FLOAT( s[i] >> 24 ); /* linear! */ + dst[i][ACOMP] = 1.0f; } } -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/7] util: Define PIPE_FORMAT_xyzw8888_{SNORM, SRGB} aliases
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already exist.
Signed-off-by: Richard Sandiford
---
src/gallium/include/pipe/p_format.h | 24
1 file changed, 24 insertions(+)
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index a0cdde3..794c1bc 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -369,6 +369,18 @@ enum pipe_format {
#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_RGBA_SNORM PIPE_FORMAT_R8G8B8A8_SNORM
+#define PIPE_FORMAT_RGBX_SNORM PIPE_FORMAT_R8G8B8X8_SNORM
+#define PIPE_FORMAT_ABGR_SNORM PIPE_FORMAT_A8B8G8R8_SNORM
+#define PIPE_FORMAT_XBGR_SNORM PIPE_FORMAT_X8B8G8R8_SNORM
+#define PIPE_FORMAT_RGBA_SRGB PIPE_FORMAT_R8G8B8A8_SRGB
+#define PIPE_FORMAT_RGBX_SRGB PIPE_FORMAT_R8G8B8X8_SRGB
+#define PIPE_FORMAT_BGRA_SRGB PIPE_FORMAT_B8G8R8A8_SRGB
+#define PIPE_FORMAT_BGRX_SRGB PIPE_FORMAT_B8G8R8X8_SRGB
+#define PIPE_FORMAT_ARGB_SRGB PIPE_FORMAT_A8R8G8B8_SRGB
+#define PIPE_FORMAT_XRGB_SRGB PIPE_FORMAT_X8R8G8B8_SRGB
+#define PIPE_FORMAT_ABGR_SRGB PIPE_FORMAT_A8B8G8R8_SRGB
+#define PIPE_FORMAT_XBGR_SRGB PIPE_FORMAT_X8B8G8R8_SRGB
#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_L8A8_UNORM
#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_A8L8_UNORM
#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_L8A8_SNORM
@@ -395,6 +407,18 @@ enum pipe_format {
#define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_ABGR_SNORM PIPE_FORMAT_R8G8B8A8_SNORM
+#define PIPE_FORMAT_XBGR_SNORM PIPE_FORMAT_R8G8B8X8_SNORM
+#define PIPE_FORMAT_RGBA_SNORM PIPE_FORMAT_A8B8G8R8_SNORM
+#define PIPE_FORMAT_RGBX_SNORM PIPE_FORMAT_X8B8G8R8_SNORM
+#define PIPE_FORMAT_ABGR_SRGB PIPE_FORMAT_R8G8B8A8_SRGB
+#define PIPE_FORMAT_XBGR_SRGB PIPE_FORMAT_R8G8B8X8_SRGB
+#define PIPE_FORMAT_ARGB_SRGB PIPE_FORMAT_B8G8R8A8_SRGB
+#define PIPE_FORMAT_XRGB_SRGB PIPE_FORMAT_B8G8R8X8_SRGB
+#define PIPE_FORMAT_BGRA_SRGB PIPE_FORMAT_A8R8G8B8_SRGB
+#define PIPE_FORMAT_BGRX_SRGB PIPE_FORMAT_X8R8G8B8_SRGB
+#define PIPE_FORMAT_RGBA_SRGB PIPE_FORMAT_A8B8G8R8_SRGB
+#define PIPE_FORMAT_RGBX_SRGB PIPE_FORMAT_X8B8G8R8_SRGB
#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_A8L8_UNORM
#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_L8A8_UNORM
#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_A8L8_SNORM
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 6/7] mesa: Add MESA_FORMAT_{A8R8G8B8, X8R8G8B8, X8B8G8R8}_SRGB
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60 +
src/mesa/main/format_unpack.c | 42 +
src/mesa/main/formats.c | 45 +++
src/mesa/main/formats.h | 3 ++
src/mesa/main/texformat.c | 10 +
src/mesa/main/texstore.c| 8 +++-
src/mesa/swrast/s_texfetch.c| 3 ++
src/mesa/swrast/s_texfetch_tmp.h| 24 ++
9 files changed, 195 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 596609e..3522fdd 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -512,6 +512,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_B5G5R5X1_UNORM] = BRW_SURFACEFORMAT_B5G5R5X1_UNORM,
[MESA_FORMAT_R8G8B8X8_SNORM] = 0,
[MESA_FORMAT_R8G8B8X8_SRGB] = 0,
+ [MESA_FORMAT_X8B8G8R8_SRGB] = 0,
[MESA_FORMAT_RGBX_UINT8] = 0,
[MESA_FORMAT_RGBX_SINT8] = 0,
[MESA_FORMAT_B10G10R10X2_UNORM] = BRW_SURFACEFORMAT_B10G10R10X2_UNORM,
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index 41253e7..6f89a72 100644
--- a/src/mesa/main/format_pack.c
+++ b/src/mesa/main/format_pack.c
@@ -1108,6 +1108,31 @@ pack_float_B8G8R8A8_SRGB(const GLfloat src[4], void *dst)
}
+/* MESA_FORMAT_A8R8G8B8_SRGB */
+
+static void
+pack_ubyte_A8R8G8B8_SRGB(const GLubyte src[4], void *dst)
+{
+ GLuint *d = ((GLuint *) dst);
+ GLubyte r = linear_ubyte_to_srgb_ubyte(src[RCOMP]);
+ GLubyte g = linear_ubyte_to_srgb_ubyte(src[GCOMP]);
+ GLubyte b = linear_ubyte_to_srgb_ubyte(src[BCOMP]);
+ *d = PACK_COLOR_(b, g, r, src[ACOMP]);
+}
+
+static void
+pack_float_A8R8G8B8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = ((GLuint *) dst);
+ GLubyte r, g, b, a;
+ r = linear_float_to_srgb_ubyte(src[RCOMP]);
+ g = linear_float_to_srgb_ubyte(src[GCOMP]);
+ b = linear_float_to_srgb_ubyte(src[BCOMP]);
+ UNCLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
+ *d = PACK_COLOR_(b, g, r, a);
+}
+
+
/* MESA_FORMAT_R8G8B8A8_SRGB */
static void
@@ -1782,6 +1807,21 @@ pack_float_R8G8B8X8_SRGB(const GLfloat src[4], void *dst)
}
+/*
+ * MESA_FORMAT_X8B8G8R8_SRGB
+ */
+
+static void
+pack_float_X8B8G8R8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = linear_float_to_srgb_ubyte(src[RCOMP]);
+ GLubyte g = linear_float_to_srgb_ubyte(src[GCOMP]);
+ GLubyte b = linear_float_to_srgb_ubyte(src[BCOMP]);
+ *d = PACK_COLOR_(r, g, b, 127);
+}
+
+
/* MESA_FORMAT_B10G10R10X2_UNORM */
static void
@@ -1931,6 +1971,20 @@ pack_float_B8G8R8X8_SRGB(const GLfloat src[4], void *dst)
*d = PACK_COLOR_(127, r, g, b);
}
+/*
+ * MESA_FORMAT_X8R8G8B8_SRGB
+ */
+
+static void
+pack_float_X8R8G8B8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLuint *d = (GLuint *) dst;
+ GLubyte r = linear_float_to_srgb_ubyte(src[RCOMP]);
+ GLubyte g = linear_float_to_srgb_ubyte(src[GCOMP]);
+ GLubyte b = linear_float_to_srgb_ubyte(src[BCOMP]);
+ *d = PACK_COLOR_(b, g, r, 127);
+}
+
/**
* Return a function that can pack a GLubyte rgba[4] color.
*/
@@ -1998,6 +2052,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_BGR_SRGB8] = pack_ubyte_BGR_SRGB8;
table[MESA_FORMAT_A8B8G8R8_SRGB] = pack_ubyte_A8B8G8R8_SRGB;
table[MESA_FORMAT_B8G8R8A8_SRGB] = pack_ubyte_B8G8R8A8_SRGB;
+ table[MESA_FORMAT_A8R8G8B8_SRGB] = pack_ubyte_A8R8G8B8_SRGB;
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_ubyte_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_ubyte_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_ubyte_L8A8_SRGB;
@@ -2072,6 +2127,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_B5G5R5X1_UNORM] = pack_ubyte_XRGB1555_UNORM;
table[MESA_FORMAT_R8G8B8X8_SNORM] = NULL;
table[MESA_FORMAT_R8G8B8X8_SRGB] = NULL;
+ table[MESA_FORMAT_X8B8G8R8_SRGB] = NULL;
table[MESA_FORMAT_RGBX_UINT8] = NULL;
table[MESA_FORMAT_RGBX_SINT8] = NULL;
table[MESA_FORMAT_B10G10R10X2_UNORM] = pack_ubyte_B10G10R10X2_UNORM;
@@ -2087,6 +2143,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_R10G10B10A2_UNORM] = pack_ubyte_R10G10B10A2_UNORM;
table[MESA_FORMAT_B8G8R8X8_SRGB] = NULL;
+ table[MESA_FORMAT_X8R8G8B8_SRGB] = NULL;
initialized = GL_TRUE;
}
@@ -2163,6 +2220,7 @@ _mesa_get_pack_float_rgba_function(mesa_format format)
table[MESA_FORMAT_BGR_SRGB8] = pack_float_BGR_SRGB8;
table[MESA_FOR
[Mesa-dev] [PATCH v2 1/7] util: Add PIPE_FORMAT_x8B8G8R8_SNORM formats
This means that each RnGnBnxn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
The associated UNORM and SRGB formats already exist.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format.csv | 3 +++
src/gallium/include/pipe/p_format.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index d01dd06..5bca5e8 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -387,3 +387,6 @@ PIPE_FORMAT_G8R8_UNORM, plain, 1, 1, un8 , un8
, , , yx01, rgb
PIPE_FORMAT_G8R8_SNORM, plain, 1, 1, sn8 , sn8 , , , yx01, rgb
PIPE_FORMAT_G16R16_UNORM , plain, 1, 1, un16, un16, , , yx01, rgb
PIPE_FORMAT_G16R16_SNORM , plain, 1, 1, sn16, sn16, , , yx01, rgb
+
+PIPE_FORMAT_A8B8G8R8_SNORM, plain, 1, 1, sn8 , sn8 , sn8 , sn8 , wzyx,
rgb
+PIPE_FORMAT_X8B8G8R8_SNORM, plain, 1, 1, x8, sn8, sn8, sn8, wzy1,
rgb
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index 1dba5b5..a0cdde3 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -354,6 +354,9 @@ enum pipe_format {
PIPE_FORMAT_G16R16_UNORM= 261,
PIPE_FORMAT_G16R16_SNORM= 262,
+ PIPE_FORMAT_A8B8G8R8_SNORM = 263,
+ PIPE_FORMAT_X8B8G8R8_SNORM = 264,
+
PIPE_FORMAT_COUNT
};
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 0/7] Fix handling of 8-bits-per-channel SRGB and SNORM formats
> Similar to the L/A and R/G series I just posted, this one fixes the SNORM
> and SRGB formats. The UNORM ones were done last year as part of the
> original big-endian work.
v2, with subject lines fixed to include the "component:" bit. No code changes
from v1.
Richard Sandiford (7):
util: Add PIPE_FORMAT_x8B8G8R8_SNORM formats
util: Define PIPE_FORMAT_xyzw_{SNORM,SRGB} aliases
mesa: Tweak unpack name for MESA_FORMAT_R8G8B8X8_SNORM
mesa: Fix alpha component in unpack_R8G8B8X8_SRGB.
mesa: Fix _mesa_texstore_signed_rgb? for big-endian.
mesa: Add MESA_FORMAT_{A8R8G8B8,X8R8G8B8,X8B8G8R8}_SRGB
st/mesa: Fix handling of SNORM and SRGB formats for big-endian
src/gallium/auxiliary/util/u_format.csv | 3 ++
src/gallium/include/pipe/p_format.h | 27 +++
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60 +
src/mesa/main/format_unpack.c | 48 ++--
src/mesa/main/formats.c | 45 +++
src/mesa/main/formats.h | 3 ++
src/mesa/main/texformat.c | 10 +
src/mesa/main/texstore.c| 14 --
src/mesa/state_tracker/st_format.c | 52 ++---
src/mesa/swrast/s_texfetch.c| 3 ++
src/mesa/swrast/s_texfetch_tmp.h| 24 ++
12 files changed, 268 insertions(+), 22 deletions(-)
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/7] mesa: Tweak unpack name for MESA_FORMAT_R8G8B8X8_SNORM
MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM
while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB.
This patch renames the SNORM function to have the same order as the
MESA_FORMAT name, like the SRGB function does.
Signed-off-by: Richard Sandiford
---
src/mesa/main/format_unpack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 7854985..ae14478 100644
--- a/src/mesa/main/format_unpack.c
+++ b/src/mesa/main/format_unpack.c
@@ -2133,7 +2133,7 @@ unpack_XRGB1555_UNORM(const void *src, GLfloat dst[][4],
GLuint n)
}
static void
-unpack_XBGR_SNORM(const void *src, GLfloat dst[][4], GLuint n)
+unpack_R8G8B8X8_SNORM(const void *src, GLfloat dst[][4], GLuint n)
{
const GLuint *s = ((const GLuint *) src);
GLuint i;
@@ -2553,7 +2553,7 @@ get_unpack_rgba_function(mesa_format format)
table[MESA_FORMAT_B4G4R4X4_UNORM] = unpack_XRGB_UNORM;
table[MESA_FORMAT_B5G5R5X1_UNORM] = unpack_XRGB1555_UNORM;
- table[MESA_FORMAT_R8G8B8X8_SNORM] = unpack_XBGR_SNORM;
+ table[MESA_FORMAT_R8G8B8X8_SNORM] = unpack_R8G8B8X8_SNORM;
table[MESA_FORMAT_R8G8B8X8_SRGB] = unpack_R8G8B8X8_SRGB;
table[MESA_FORMAT_RGBX_UINT8] = unpack_XBGR_UINT;
table[MESA_FORMAT_RGBX_SINT8] = unpack_XBGR_SINT;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 7/7] st/mesa: Fix handling of 8888 SNORM and SRGB formats for big-endian
MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw. PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signed-off-by: Richard Sandiford --- src/mesa/state_tracker/st_format.c | 52 ++ 1 file changed, 36 insertions(+), 16 deletions(-) diff --git a/src/mesa/state_tracker/st_format.c b/src/mesa/state_tracker/st_format.c index 59cde2e..1e0a401 100644 --- a/src/mesa/state_tracker/st_format.c +++ b/src/mesa/state_tracker/st_format.c @@ -154,11 +154,13 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_BGR_SRGB8: return PIPE_FORMAT_R8G8B8_SRGB; case MESA_FORMAT_A8B8G8R8_SRGB: - return PIPE_FORMAT_A8B8G8R8_SRGB; - case MESA_FORMAT_B8G8R8A8_SRGB: - return PIPE_FORMAT_B8G8R8A8_SRGB; + return PIPE_FORMAT_ABGR_SRGB; case MESA_FORMAT_R8G8B8A8_SRGB: - return PIPE_FORMAT_R8G8B8A8_SRGB; + return PIPE_FORMAT_RGBA_SRGB; + case MESA_FORMAT_B8G8R8A8_SRGB: + return PIPE_FORMAT_BGRA_SRGB; + case MESA_FORMAT_A8R8G8B8_SRGB: + return PIPE_FORMAT_ARGB_SRGB; case MESA_FORMAT_RGBA_FLOAT32: return PIPE_FORMAT_R32G32B32A32_FLOAT; case MESA_FORMAT_RGBA_FLOAT16: @@ -344,7 +346,9 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_G8R8_SNORM: return PIPE_FORMAT_GR88_SNORM; case MESA_FORMAT_R8G8B8A8_SNORM: - return PIPE_FORMAT_R8G8B8A8_SNORM; + return PIPE_FORMAT_RGBA_SNORM; + case MESA_FORMAT_A8B8G8R8_SNORM: + return PIPE_FORMAT_ABGR_SNORM; case MESA_FORMAT_A_SNORM8: return PIPE_FORMAT_A8_SNORM; @@ -389,9 +393,13 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_B5G5R5X1_UNORM: return PIPE_FORMAT_B5G5R5X1_UNORM; case MESA_FORMAT_R8G8B8X8_SNORM: - return PIPE_FORMAT_R8G8B8X8_SNORM; + return PIPE_FORMAT_RGBX_SNORM; + case MESA_FORMAT_X8B8G8R8_SNORM: + return PIPE_FORMAT_XBGR_SNORM; case MESA_FORMAT_R8G8B8X8_SRGB: - return PIPE_FORMAT_R8G8B8X8_SRGB; + return PIPE_FORMAT_RGBX_SRGB; + case MESA_FORMAT_X8B8G8R8_SRGB: + return PIPE_FORMAT_XBGR_SRGB; case MESA_FORMAT_RGBX_UINT8: return PIPE_FORMAT_R8G8B8X8_UINT; case MESA_FORMAT_RGBX_SINT8: @@ -416,7 +424,9 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) return PIPE_FORMAT_R32G32B32X32_SINT; case MESA_FORMAT_B8G8R8X8_SRGB: - return PIPE_FORMAT_B8G8R8X8_SRGB; + return PIPE_FORMAT_BGRX_SRGB; + case MESA_FORMAT_X8R8G8B8_SRGB: + return PIPE_FORMAT_XRGB_SRGB; default: return PIPE_FORMAT_NONE; @@ -533,10 +543,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_L_SRGB8; case PIPE_FORMAT_R8G8B8_SRGB: return MESA_FORMAT_BGR_SRGB8; - case PIPE_FORMAT_A8B8G8R8_SRGB: + case PIPE_FORMAT_ABGR_SRGB: return MESA_FORMAT_A8B8G8R8_SRGB; - case PIPE_FORMAT_B8G8R8A8_SRGB: + case PIPE_FORMAT_RGBA_SRGB: + return MESA_FORMAT_R8G8B8A8_SRGB; + case PIPE_FORMAT_BGRA_SRGB: return MESA_FORMAT_B8G8R8A8_SRGB; + case PIPE_FORMAT_ARGB_SRGB: + return MESA_FORMAT_A8R8G8B8_SRGB; case PIPE_FORMAT_R32G32B32A32_FLOAT: return MESA_FORMAT_RGBA_FLOAT32; case PIPE_FORMAT_R16G16B16A16_FLOAT: @@ -718,8 +732,10 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_R8G8_SNORM; case PIPE_FORMAT_GR88_SNORM: return MESA_FORMAT_G8R8_SNORM; - case PIPE_FORMAT_R8G8B8A8_SNORM: + case PIPE_FORMAT_RGBA_SNORM: return MESA_FORMAT_R8G8B8A8_SNORM; + case PIPE_FORMAT_ABGR_SNORM: + return MESA_FORMAT_A8B8G8R8_SNORM; case PIPE_FORMAT_A8_SNORM: return MESA_FORMAT_A_SNORM8; @@ -764,10 +780,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_B4G4R4X4_UNORM; case PIPE_FORMAT_B5G5R5X1_UNORM: return MESA_FORMAT_B5G5R5X1_UNORM; - case PIPE_FORMAT_R8G8B8X8_SNORM: + case PIPE_FORMAT_RGBX_SNORM: return MESA_FORMAT_R8G8B8X8_SNORM; - case PIPE_FORMAT_R8G8B8X8_SRGB: + case PIPE_FORMAT_XBGR_SNORM: + return MESA_FORMAT_X8B8G8R8_SNORM; + case PIPE_FORMAT_RGBX_SRGB: return MESA_FORMAT_R8G8B8X8_SRGB; + case PIPE_FORMAT_XBGR_SRGB: + return MESA_FORMAT_X8B8G8R8_SRGB; case PIPE_FORMAT_R8G8B8X8_UINT: return MESA_FORMAT_RGBX_UINT8; case PIPE_FORMAT_R8G8B8X8_SINT: @@ -791,10 +811,10 @@ st_pipe_format_to_mesa_format(enum pipe_format format) case PIPE_FORMAT_R32G32B32X32_SINT: return MESA_FORMAT_RGBX_SINT32; - case PIPE_FORMAT_B8G8R8X8_SRGB: + case PIPE_FORMAT_BGRX_SRGB: return MESA_FORMAT_B8G8R8X8_SRGB; - case PIPE_FORMAT_R8G8B8A8_SRGB: - return MESA_FORMAT_R8G8B8A8_SRGB; + case PIPE_FORMAT_XRGB
[Mesa-dev] [Bug 79949] [DRI3] GTK+ Programs Not Updating Correctly
https://bugs.freedesktop.org/show_bug.cgi?id=79949 drag...@gmail.com changed: What|Removed |Added Status|NEW |NEEDINFO CC||drag...@gmail.com --- Comment #9 from drag...@gmail.com --- This is the same as bug 81551 ... can you test Chris's patch and confirm whether it works or not? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/17] i965/gen6 fbo: make unmatched depth/stencil configs return unsupported
On Fri, Jul 18, 2014 at 02:16:45PM -0700, Jordan Justen wrote:
> (f3c886b for gen6)
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/intel_fbo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
> b/src/mesa/drivers/dri/i965/intel_fbo.c
> index e43e18b..22f707f 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
> @@ -673,8 +673,8 @@ intel_validate_framebuffer(struct gl_context *ctx, struct
> gl_framebuffer *fb)
> }
>
> if (depth_mt && stencil_mt) {
> - if (brw->gen >= 7) {
> - /* For gen >= 7, we are using the lod/minimum-array-element fields
> + if (brw->gen >= 6) {
> + /* For gen >= 6, we are using the lod/minimum-array-element fields
>* and supportting layered rendering. This means that we must
> restrict
You could also fix the typo (supportting) while at it:
Reviewed-by: Topi Pohjolainen
>* the depth & stencil attachments to match in various more
> retrictive
>* ways. (width, height, depth, LOD and layer)
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/5] util: Define PIPE_FORMAT_{LA, AL, RG, GR}nn aliases
...i.e. formats in which the first listed component is in the least
significant half of the integer.
Signed-off-by: Richard Sandiford
---
src/gallium/include/pipe/p_format.h | 32
1 file changed, 32 insertions(+)
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index 48af05b..1dba5b5 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -366,6 +366,22 @@ enum pipe_format {
#define PIPE_FORMAT_XRGB_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_L8A8_UNORM
+#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_A8L8_UNORM
+#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_L8A8_SNORM
+#define PIPE_FORMAT_AL88_SNORM PIPE_FORMAT_A8L8_SNORM
+#define PIPE_FORMAT_LA88_SRGB PIPE_FORMAT_L8A8_SRGB
+#define PIPE_FORMAT_AL88_SRGB PIPE_FORMAT_A8L8_SRGB
+#define PIPE_FORMAT_LA1616_UNORM PIPE_FORMAT_L16A16_UNORM
+#define PIPE_FORMAT_AL1616_UNORM PIPE_FORMAT_A16L16_UNORM
+#define PIPE_FORMAT_RG88_UNORM PIPE_FORMAT_R8G8_UNORM
+#define PIPE_FORMAT_GR88_UNORM PIPE_FORMAT_G8R8_UNORM
+#define PIPE_FORMAT_RG88_SNORM PIPE_FORMAT_R8G8_SNORM
+#define PIPE_FORMAT_GR88_SNORM PIPE_FORMAT_G8R8_SNORM
+#define PIPE_FORMAT_RG1616_UNORM PIPE_FORMAT_R16G16_UNORM
+#define PIPE_FORMAT_GR1616_UNORM PIPE_FORMAT_G16R16_UNORM
+#define PIPE_FORMAT_RG1616_SNORM PIPE_FORMAT_R16G16_SNORM
+#define PIPE_FORMAT_GR1616_SNORM PIPE_FORMAT_G16R16_SNORM
#elif defined(PIPE_ARCH_BIG_ENDIAN)
#define PIPE_FORMAT_ABGR_UNORM PIPE_FORMAT_R8G8B8A8_UNORM
#define PIPE_FORMAT_XBGR_UNORM PIPE_FORMAT_R8G8B8X8_UNORM
@@ -376,6 +392,22 @@ enum pipe_format {
#define PIPE_FORMAT_BGRX_UNORM PIPE_FORMAT_X8R8G8B8_UNORM
#define PIPE_FORMAT_RGBA_UNORM PIPE_FORMAT_A8B8G8R8_UNORM
#define PIPE_FORMAT_RGBX_UNORM PIPE_FORMAT_X8B8G8R8_UNORM
+#define PIPE_FORMAT_LA88_UNORM PIPE_FORMAT_A8L8_UNORM
+#define PIPE_FORMAT_AL88_UNORM PIPE_FORMAT_L8A8_UNORM
+#define PIPE_FORMAT_LA88_SNORM PIPE_FORMAT_A8L8_SNORM
+#define PIPE_FORMAT_AL88_SNORM PIPE_FORMAT_L8A8_SNORM
+#define PIPE_FORMAT_LA88_SRGB PIPE_FORMAT_A8L8_SRGB
+#define PIPE_FORMAT_AL88_SRGB PIPE_FORMAT_L8A8_SRGB
+#define PIPE_FORMAT_LA1616_UNORM PIPE_FORMAT_A16L16_UNORM
+#define PIPE_FORMAT_AL1616_UNORM PIPE_FORMAT_L16A16_UNORM
+#define PIPE_FORMAT_RG88_UNORM PIPE_FORMAT_G8R8_UNORM
+#define PIPE_FORMAT_GR88_UNORM PIPE_FORMAT_R8G8_UNORM
+#define PIPE_FORMAT_RG88_SNORM PIPE_FORMAT_G8R8_SNORM
+#define PIPE_FORMAT_GR88_SNORM PIPE_FORMAT_R8G8_SNORM
+#define PIPE_FORMAT_RG1616_UNORM PIPE_FORMAT_G16R16_UNORM
+#define PIPE_FORMAT_GR1616_UNORM PIPE_FORMAT_R16G16_UNORM
+#define PIPE_FORMAT_RG1616_SNORM PIPE_FORMAT_G16R16_SNORM
+#define PIPE_FORMAT_GR1616_SNORM PIPE_FORMAT_R16G16_SNORM
#endif
enum pipe_video_chroma_format
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/5] util: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnRn formats
...i.e. formats in which the alpha or green channel is first in memory.
This means that each LnAn and RnGn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/util/u_format.csv | 9 +
src/gallium/include/pipe/p_format.h | 10 ++
2 files changed, 19 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index 1cd4954..d01dd06 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -378,3 +378,12 @@ PIPE_FORMAT_R10G10B10A2_UINT, plain, 1, 1, up10 ,
up10 , up10, up2 , xyz
PIPE_FORMAT_B5G6R5_SRGB , plain, 1, 1, un5 , un6 , un5 , ,
zyx1, srgb, un5 , un6 , un5 , , xyz1
+PIPE_FORMAT_A8L8_UNORM, plain, 1, 1, un8 , un8 , , , yyyx, rgb
+PIPE_FORMAT_A8L8_SNORM, plain, 1, 1, sn8 , sn8 , , , yyyx, rgb
+PIPE_FORMAT_A8L8_SRGB , plain, 1, 1, un8 , un8 , , , yyyx, srgb
+PIPE_FORMAT_A16L16_UNORM , plain, 1, 1, un16, un16, , , yyyx, rgb
+
+PIPE_FORMAT_G8R8_UNORM, plain, 1, 1, un8 , un8 , , , yx01, rgb
+PIPE_FORMAT_G8R8_SNORM, plain, 1, 1, sn8 , sn8 , , , yx01, rgb
+PIPE_FORMAT_G16R16_UNORM , plain, 1, 1, un16, un16, , , yx01, rgb
+PIPE_FORMAT_G16R16_SNORM , plain, 1, 1, sn16, sn16, , , yx01, rgb
diff --git a/src/gallium/include/pipe/p_format.h
b/src/gallium/include/pipe/p_format.h
index a7fdcd0..48af05b 100644
--- a/src/gallium/include/pipe/p_format.h
+++ b/src/gallium/include/pipe/p_format.h
@@ -344,6 +344,16 @@ enum pipe_format {
PIPE_FORMAT_B5G6R5_SRGB = 254,
+ PIPE_FORMAT_A8L8_UNORM = 255,
+ PIPE_FORMAT_A8L8_SNORM = 256,
+ PIPE_FORMAT_A8L8_SRGB = 257,
+ PIPE_FORMAT_A16L16_UNORM= 258,
+
+ PIPE_FORMAT_G8R8_UNORM = 259,
+ PIPE_FORMAT_G8R8_SNORM = 260,
+ PIPE_FORMAT_G16R16_UNORM= 261,
+ PIPE_FORMAT_G16R16_SNORM= 262,
+
PIPE_FORMAT_COUNT
};
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 5/5] st/mesa: Fix handling of LA and RG formats for big-endian
MESA_FORMAT_LnAn puts the luminance in the least significant part of the containing integer, which is equivalent to PIPE_FORMAT_LAnn. PIPE_FORMAT_LnAn puts the luminance first in memory. This patch fixes up the mesa<->gallium mapping accordingly. Signed-off-by: Richard Sandiford --- src/mesa/state_tracker/st_format.c | 64 -- 1 file changed, 48 insertions(+), 16 deletions(-) diff --git a/src/mesa/state_tracker/st_format.c b/src/mesa/state_tracker/st_format.c index 409079b..59cde2e 100644 --- a/src/mesa/state_tracker/st_format.c +++ b/src/mesa/state_tracker/st_format.c @@ -88,9 +88,13 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_L4A4_UNORM: return PIPE_FORMAT_L4A4_UNORM; case MESA_FORMAT_L8A8_UNORM: - return PIPE_FORMAT_L8A8_UNORM; + return PIPE_FORMAT_LA88_UNORM; + case MESA_FORMAT_A8L8_UNORM: + return PIPE_FORMAT_AL88_UNORM; case MESA_FORMAT_L16A16_UNORM: - return PIPE_FORMAT_L16A16_UNORM; + return PIPE_FORMAT_LA1616_UNORM; + case MESA_FORMAT_A16L16_UNORM: + return PIPE_FORMAT_AL1616_UNORM; case MESA_FORMAT_A_UNORM8: return PIPE_FORMAT_A8_UNORM; case MESA_FORMAT_A_UNORM16: @@ -142,7 +146,9 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_SRGBA_DXT5: return PIPE_FORMAT_DXT5_SRGBA; case MESA_FORMAT_L8A8_SRGB: - return PIPE_FORMAT_L8A8_SRGB; + return PIPE_FORMAT_LA88_SRGB; + case MESA_FORMAT_A8L8_SRGB: + return PIPE_FORMAT_AL88_SRGB; case MESA_FORMAT_L_SRGB8: return PIPE_FORMAT_L8_SRGB; case MESA_FORMAT_BGR_SRGB8: @@ -191,9 +197,13 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_R_UNORM16: return PIPE_FORMAT_R16_UNORM; case MESA_FORMAT_R8G8_UNORM: - return PIPE_FORMAT_R8G8_UNORM; + return PIPE_FORMAT_RG88_UNORM; + case MESA_FORMAT_G8R8_UNORM: + return PIPE_FORMAT_GR88_UNORM; case MESA_FORMAT_R16G16_UNORM: - return PIPE_FORMAT_R16G16_UNORM; + return PIPE_FORMAT_RG1616_UNORM; + case MESA_FORMAT_G16R16_UNORM: + return PIPE_FORMAT_GR1616_UNORM; case MESA_FORMAT_RGBA_UNORM16: return PIPE_FORMAT_R16G16B16A16_UNORM; @@ -330,7 +340,9 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_R_SNORM8: return PIPE_FORMAT_R8_SNORM; case MESA_FORMAT_R8G8_SNORM: - return PIPE_FORMAT_R8G8_SNORM; + return PIPE_FORMAT_RG88_SNORM; + case MESA_FORMAT_G8R8_SNORM: + return PIPE_FORMAT_GR88_SNORM; case MESA_FORMAT_R8G8B8A8_SNORM: return PIPE_FORMAT_R8G8B8A8_SNORM; @@ -339,14 +351,18 @@ st_mesa_format_to_pipe_format(mesa_format mesaFormat) case MESA_FORMAT_L_SNORM8: return PIPE_FORMAT_L8_SNORM; case MESA_FORMAT_L8A8_SNORM: - return PIPE_FORMAT_L8A8_SNORM; + return PIPE_FORMAT_LA88_SNORM; + case MESA_FORMAT_A8L8_SNORM: + return PIPE_FORMAT_AL88_SNORM; case MESA_FORMAT_I_SNORM8: return PIPE_FORMAT_I8_SNORM; case MESA_FORMAT_R_SNORM16: return PIPE_FORMAT_R16_SNORM; case MESA_FORMAT_R16G16_SNORM: - return PIPE_FORMAT_R16G16_SNORM; + return PIPE_FORMAT_RG1616_SNORM; + case MESA_FORMAT_G16R16_SNORM: + return PIPE_FORMAT_GR1616_SNORM; case MESA_FORMAT_RGBA_SNORM16: return PIPE_FORMAT_R16G16B16A16_SNORM; @@ -445,10 +461,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_R10G10B10A2_UNORM; case PIPE_FORMAT_L4A4_UNORM: return MESA_FORMAT_L4A4_UNORM; - case PIPE_FORMAT_L8A8_UNORM: + case PIPE_FORMAT_LA88_UNORM: return MESA_FORMAT_L8A8_UNORM; - case PIPE_FORMAT_L16A16_UNORM: + case PIPE_FORMAT_AL88_UNORM: + return MESA_FORMAT_A8L8_UNORM; + case PIPE_FORMAT_LA1616_UNORM: return MESA_FORMAT_L16A16_UNORM; + case PIPE_FORMAT_AL1616_UNORM: + return MESA_FORMAT_A16L16_UNORM; case PIPE_FORMAT_A8_UNORM: return MESA_FORMAT_A_UNORM8; case PIPE_FORMAT_A16_UNORM: @@ -505,8 +525,10 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_SRGBA_DXT3; case PIPE_FORMAT_DXT5_SRGBA: return MESA_FORMAT_SRGBA_DXT5; - case PIPE_FORMAT_L8A8_SRGB: + case PIPE_FORMAT_LA88_SRGB: return MESA_FORMAT_L8A8_SRGB; + case PIPE_FORMAT_AL88_SRGB: + return MESA_FORMAT_A8L8_SRGB; case PIPE_FORMAT_L8_SRGB: return MESA_FORMAT_L_SRGB8; case PIPE_FORMAT_R8G8B8_SRGB: @@ -552,10 +574,14 @@ st_pipe_format_to_mesa_format(enum pipe_format format) return MESA_FORMAT_R_UNORM8; case PIPE_FORMAT_R16_UNORM: return MESA_FORMAT_R_UNORM16; - case PIPE_FORMAT_R8G8_UNORM: + case PIPE_FORMAT_RG88_UNORM: return MESA_FORMAT_R8G8_UNORM; - case PIPE_FORMAT_R16G16_UNORM: + case PIPE_FORMAT_GR88_UNORM: + return MESA_FORMAT_G8R8_UNORM; + case PIPE_FORMAT_RG1616_UNORM: return MESA_FORMAT_R16G16_UNORM; + case PIPE_FORMAT_GR1616_UNORM: + retu
[Mesa-dev] [PATCH v2 0/5] Fix handling of LnAn and RnGn formats for big-endian
> MESA_FORMAT_LnAn_* puts the luminance in the low part of the integer and
> the alpha in the high part. The same goes for MESA_FORMAT_RnGn with the
> red and green channels.
>
> This series fixes gallium to be consistent with that layout on big-endian.
> Following the convention established last year, PIPE_FORMAT_LAnn and
> PIPE_FORMAT_RGnn are the equivalent gallium formats. Where defined,
> PIPE_FORMAT_LnAn puts the luminance first in memory and the alpha
> last in memory.
>
> Patch 1 also fixes an endianness bug in mesa swrast for MESA_FORMAT_L8A8_SRGB.
> AFAICT all other L/A and R/G formats are handled correctly.
v2, with subject lines fixed to include the "component:" bit. No code changes
from v1.
Richard Sandiford (5):
swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endian
util: Add PIPE_FORMAT_AnLn and PIPE_FORMAT_GnRn formats
util: Define PIPE_FORMAT_{LA,AL,RG,GR}nn aliases
mesa: Add MESA_FORMAT_A8L8_{SNORM,SRGB}
st/mesa: Fix handling of LA and RG formats for big-endian
src/gallium/auxiliary/util/u_format.csv | 9
src/gallium/include/pipe/p_format.h | 42
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 +
src/mesa/main/format_pack.c | 37 ++
src/mesa/main/format_unpack.c | 29 +++
src/mesa/main/formats.c | 28 +++
src/mesa/main/formats.h | 2 +
src/mesa/main/texformat.c | 3 ++
src/mesa/main/texstore.c| 10 +++-
src/mesa/state_tracker/st_format.c | 64 ++---
src/mesa/swrast/s_texfetch.c| 2 +
src/mesa/swrast/s_texfetch_tmp.h| 30 ++--
12 files changed, 237 insertions(+), 21 deletions(-)
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/5] swrast: Fix handling of MESA_FORMAT_L8A8_SRGB for big-endian
Luminance is the least-significant byte of the uint16, rather than the
lowest byte in memory. Other parts of mesa already handle this correctly
for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats
correctly. This case was just an odd-one-out.
Signed-off-by: Richard Sandiford
---
src/mesa/swrast/s_texfetch_tmp.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/swrast/s_texfetch_tmp.h b/src/mesa/swrast/s_texfetch_tmp.h
index deda592..0fce355 100644
--- a/src/mesa/swrast/s_texfetch_tmp.h
+++ b/src/mesa/swrast/s_texfetch_tmp.h
@@ -808,11 +808,11 @@ static void
FETCH(L8A8_SRGB)(const struct swrast_texture_image *texImage,
GLint i, GLint j, GLint k, GLfloat *texel)
{
- const GLubyte *src = TEXEL_ADDR(GLubyte, texImage, i, j, k, 2);
+ const GLushort s = *TEXEL_ADDR(GLushort, texImage, i, j, k, 1);
texel[RCOMP] =
texel[GCOMP] =
- texel[BCOMP] = nonlinear_to_linear(src[0]);
- texel[ACOMP] = UBYTE_TO_FLOAT(src[1]); /* linear */
+ texel[BCOMP] = nonlinear_to_linear(s & 0xff);
+ texel[ACOMP] = UBYTE_TO_FLOAT(s >> 8); /* linear */
}
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/5] mesa: Add MESA_FORMAT_A8L8_{SNORM,SRGB}
The associated UNORM format already existed.
This means that each LnAn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
Signed-off-by: Richard Sandiford
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mesa/main/format_pack.c | 37 +
src/mesa/main/format_unpack.c | 29 +++
src/mesa/main/formats.c | 28 +++
src/mesa/main/formats.h | 2 ++
src/mesa/main/texformat.c | 3 ++
src/mesa/main/texstore.c| 10 +--
src/mesa/swrast/s_texfetch.c| 2 ++
src/mesa/swrast/s_texfetch_tmp.h| 24
9 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 41f4221..596609e 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -371,6 +371,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_R8G8B8A8_SRGB] = BRW_SURFACEFORMAT_R8G8B8A8_UNORM_SRGB,
[MESA_FORMAT_L_SRGB8] = BRW_SURFACEFORMAT_L8_UNORM_SRGB,
[MESA_FORMAT_L8A8_SRGB] = BRW_SURFACEFORMAT_L8A8_UNORM_SRGB,
+ [MESA_FORMAT_A8L8_SRGB] = 0,
[MESA_FORMAT_SRGB_DXT1] = BRW_SURFACEFORMAT_DXT1_RGB_SRGB,
[MESA_FORMAT_SRGBA_DXT1] = BRW_SURFACEFORMAT_BC1_UNORM_SRGB,
[MESA_FORMAT_SRGBA_DXT3] = BRW_SURFACEFORMAT_BC2_UNORM_SRGB,
@@ -490,6 +491,7 @@ brw_format_for_mesa_format(mesa_format mesa_format)
[MESA_FORMAT_A_SNORM8] = 0,
[MESA_FORMAT_L_SNORM8] = 0,
[MESA_FORMAT_L8A8_SNORM] = 0,
+ [MESA_FORMAT_A8L8_SNORM] = 0,
[MESA_FORMAT_I_SNORM8] = 0,
[MESA_FORMAT_A_SNORM16] = 0,
[MESA_FORMAT_L_SNORM16] = 0,
diff --git a/src/mesa/main/format_pack.c b/src/mesa/main/format_pack.c
index c97c052..41253e7 100644
--- a/src/mesa/main/format_pack.c
+++ b/src/mesa/main/format_pack.c
@@ -1161,6 +1161,16 @@ pack_ubyte_L8A8_SRGB(const GLubyte src[4], void *dst)
*d = PACK_COLOR_88(src[ACOMP], l);
}
+/* MESA_FORMAT_A8L8_SRGB */
+
+static void
+pack_ubyte_A8L8_SRGB(const GLubyte src[4], void *dst)
+{
+ GLushort *d = ((GLushort *) dst);
+ GLubyte l = linear_ubyte_to_srgb_ubyte(src[RCOMP]);
+ *d = PACK_COLOR_88(l, src[ACOMP]);
+}
+
static void
pack_float_L8A8_SRGB(const GLfloat src[4], void *dst)
{
@@ -1170,6 +1180,15 @@ pack_float_L8A8_SRGB(const GLfloat src[4], void *dst)
*d = PACK_COLOR_88(a, l);
}
+static void
+pack_float_A8L8_SRGB(const GLfloat src[4], void *dst)
+{
+ GLushort *d = ((GLushort *) dst);
+ GLubyte a, l = linear_float_to_srgb_ubyte(src[RCOMP]);
+ CLAMPED_FLOAT_TO_UBYTE(a, src[ACOMP]);
+ *d = PACK_COLOR_88(l, a);
+}
+
/* MESA_FORMAT_RGBA_FLOAT32 */
@@ -1595,6 +1614,20 @@ pack_float_L8A8_SNORM(const GLfloat src[4], void *dst)
/*
+ * MESA_FORMAT_A8L8_SNORM
+ */
+
+static void
+pack_float_A8L8_SNORM(const GLfloat src[4], void *dst)
+{
+ GLushort *d = (GLushort *) dst;
+ GLbyte l = FLOAT_TO_BYTE(CLAMP(src[RCOMP], -1.0f, 1.0f));
+ GLbyte a = FLOAT_TO_BYTE(CLAMP(src[ACOMP], -1.0f, 1.0f));
+ *d = (l << 8) | a;
+}
+
+
+/*
* MESA_FORMAT_A_SNORM16
*/
@@ -1968,6 +2001,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_ubyte_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_ubyte_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_ubyte_L8A8_SRGB;
+ table[MESA_FORMAT_A8L8_SRGB] = pack_ubyte_A8L8_SRGB;
/* n/a */
table[MESA_FORMAT_SRGB_DXT1] = NULL; /* pack_ubyte_SRGB_DXT1; */
table[MESA_FORMAT_SRGBA_DXT1] = NULL; /* pack_ubyte_SRGBA_DXT1; */
@@ -2021,6 +2055,7 @@ _mesa_get_pack_ubyte_rgba_function(mesa_format format)
table[MESA_FORMAT_A_SNORM8] = NULL;
table[MESA_FORMAT_L_SNORM8] = NULL;
table[MESA_FORMAT_L8A8_SNORM] = NULL;
+ table[MESA_FORMAT_A8L8_SNORM] = NULL;
table[MESA_FORMAT_I_SNORM8] = NULL;
table[MESA_FORMAT_A_SNORM16] = NULL;
table[MESA_FORMAT_L_SNORM16] = NULL;
@@ -2131,6 +2166,7 @@ _mesa_get_pack_float_rgba_function(mesa_format format)
table[MESA_FORMAT_R8G8B8A8_SRGB] = pack_float_R8G8B8A8_SRGB;
table[MESA_FORMAT_L_SRGB8] = pack_float_L_SRGB8;
table[MESA_FORMAT_L8A8_SRGB] = pack_float_L8A8_SRGB;
+ table[MESA_FORMAT_A8L8_SRGB] = pack_float_A8L8_SRGB;
/* n/a */
table[MESA_FORMAT_SRGB_DXT1] = NULL;
@@ -2185,6 +2221,7 @@ _mesa_get_pack_float_rgba_function(mesa_format format)
table[MESA_FORMAT_A_SNORM8] = pack_float_A_SNORM8;
table[MESA_FORMAT_L_SNORM8] = pack_float_L_SNORM8;
table[MESA_FORMAT_L8A8_SNORM] = pack_float_L8A8_SNORM;
+ table[MESA_FORMAT_A8L8_SNORM] = pack_float_A8L8_SNORM;
table[MESA_FORMAT_I_SNORM8] = pack_float_L_SNORM8; /* reused *
Re: [Mesa-dev] [PATCH 0/7] Fix handling of 8-bits-per-channel SRGB and SNORM formats
Marek Olšák writes: > Hi Richard, > > For anything that changes the shared core code in src/gallium, the > commit message prefix should be "gallium:". You can also use > "gallium/util:" if you just change auxiliary/util. > > For anything that changes src/mesa/state_tracker, the prefix should be > "st/mesa:". > > For anything that changes src/mesa/main, the prefix should be "mesa:". > > Commits lacking a prefix followed by ":" are not allowed. Ah, thanks for the heads-up. I'll resend the two 0/7 series shortly with fixed commit messages. Thanks, Richard ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: Add util_memcpy_cpu_to_le32() v3
On 19.07.2014 04:55, Tom Stellard wrote:
> v2:
> - Preserve word boundaries.
>
> v3:
> - Use const and restrict.
> - Fix indentation.
> ---
> src/gallium/auxiliary/util/u_math.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_math.h
> b/src/gallium/auxiliary/util/u_math.h
> index b9ed197..f6dcb22 100644
> --- a/src/gallium/auxiliary/util/u_math.h
> +++ b/src/gallium/auxiliary/util/u_math.h
> @@ -812,6 +812,23 @@ util_bswap16(uint16_t n)
>(n << 8);
> }
>
> +static INLINE void*
> +util_memcpy_cpu_to_le32(void * restrict dest, const void * restrict src,
> size_t n)
> +{
> +#ifdef PIPE_ARCH_BIG_ENDIAN
> + size_t i, e;
> + asset(n % 4 == 0);
> +
> + for (i = 0, e = n / 4; i < e; i++) {
> + uint32_t * restrict d = (uint32_t* restrict)dest;
> + const uint32_t * restrict s = (const uint32_t* restrict)src;
> + d[i] = util_bswap32(s[i]);
> + }
> + return dest;
> +#else
> + return memcpy(dest, src, n);
> +#endif
> +}
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/17] i965/gen6 depth surface: calculate more specific surface type
On Fri, Jul 18, 2014 at 02:16:40PM -0700, Jordan Justen wrote:
> (171e633 for gen6)
>
> This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
>
> Note: Cube maps are treated as 2D arrays with 6 times as
> many array elements as the cube map array would have.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 17 ++
> src/mesa/drivers/dri/i965/gen6_depth_state.c | 33
>
> 2 files changed, 50 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> index eb865b9..3fc36aa 100644
> --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> @@ -791,6 +791,23 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
> *brw,
> uint32_t draw_x = params->depth.x_offset;
> uint32_t draw_y = params->depth.y_offset;
> uint32_t tile_mask_x, tile_mask_y;
> + uint32_t surftype;
> + GLenum gl_target = params->depth.mt->target;
> +
> + switch (gl_target) {
> + case GL_TEXTURE_CUBE_MAP_ARRAY:
> + case GL_TEXTURE_CUBE_MAP:
> + /* The PRM claims that we should use BRW_SURFACE_CUBE for this
> + * situation, but experiments show that gl_Layer doesn't work when we
> do
> + * this. So we use BRW_SURFACE_2D, since for rendering purposes this
> is
> + * equivalent.
> + */
> + surftype = BRW_SURFACE_2D;
> + break;
> + default:
> + surftype = translate_tex_target(gl_target);
> + break;
> + }
Patches 5-7 look identical to the gen7 equivalent and hence in principle:
Reviewed-by: Topi Pohjolainen
But having said that I think we need to start planning how to merge all the
duplicate surface state logic between gen6-gen8. For example, the switch
statement above can be now found twice per generation.
>
> brw_get_depthstencil_tile_masks(params->depth.mt,
> params->depth.level,
> diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> index d37aae8..0480142 100644
> --- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> @@ -30,6 +30,7 @@
> #include "brw_state.h"
> #include "brw_defines.h"
>
> +#include "main/mtypes.h"
> #include "main/fbobject.h"
> #include "main/glformats.h"
>
> @@ -43,6 +44,13 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
> uint32_t width, uint32_t height,
> uint32_t tile_x, uint32_t tile_y)
> {
> + struct gl_context *ctx = &brw->ctx;
> + struct gl_framebuffer *fb = ctx->DrawBuffer;
> + uint32_t surftype;
> + GLenum gl_target = GL_TEXTURE_2D;
> + const struct intel_renderbuffer *irb = NULL;
> + const struct gl_renderbuffer *rb = NULL;
> +
> /* Enable the hiz bit if we're doing separate stencil, because it and the
> * separate stencil bit must have the same value. From Section
> 2.11.5.6.1.1
> * 3DSTATE_DEPTH_BUFFER, Bit 1.21 "Separate Stencil Enable":
> @@ -63,6 +71,31 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
>intel_emit_depth_stall_flushes(brw);
> }
>
> + irb = intel_get_renderbuffer(fb, BUFFER_DEPTH);
> + if (!irb)
> + irb = intel_get_renderbuffer(fb, BUFFER_STENCIL);
> + rb = (struct gl_renderbuffer*) irb;
> +
> + if (rb) {
> + if (rb->TexImage)
> + gl_target = rb->TexImage->TexObject->Target;
> + }
> +
> + switch (gl_target) {
> + case GL_TEXTURE_CUBE_MAP_ARRAY:
> + case GL_TEXTURE_CUBE_MAP:
> + /* The PRM claims that we should use BRW_SURFACE_CUBE for this
> + * situation, but experiments show that gl_Layer doesn't work when we
> do
> + * this. So we use BRW_SURFACE_2D, since for rendering purposes this
> is
> + * equivalent.
> + */
> + surftype = BRW_SURFACE_2D;
> + break;
> + default:
> + surftype = translate_tex_target(gl_target);
> + break;
> + }
> +
> unsigned int len;
> if (brw->gen >= 6)
>len = 7;
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/17] i965/gen6 depth surface: calculate minimum array element being rendered
On Fri, Jul 18, 2014 at 02:16:43PM -0700, Jordan Justen wrote:
> (a23cfb8 for gen6)
>
> In layered rendering this will be 0. Otherwise it will be the
> selected slice.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/gen6_blorp.cpp | 3 +++
> src/mesa/drivers/dri/i965/gen6_depth_state.c | 10 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> index 131c4aa..ff1732d 100644
> --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
> @@ -793,6 +793,7 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
> *brw,
> uint32_t tile_mask_x, tile_mask_y;
> uint32_t surftype;
> unsigned int depth = MAX2(params->depth.mt->logical_depth0, 1);
> + unsigned int min_array_element;
> GLenum gl_target = params->depth.mt->target;
> unsigned int lod;
>
> @@ -818,6 +819,8 @@ gen6_blorp_emit_depth_stencil_config(struct brw_context
> *brw,
> NULL,
> &tile_mask_x, &tile_mask_y);
>
> + min_array_element = params->depth.layer;
> +
> lod = params->depth.level - params->depth.mt->first_level;
>
> /* 3DSTATE_DEPTH_BUFFER */
> diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> index 8ee7c00..abb2124 100644
> --- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> @@ -48,6 +48,7 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
> struct gl_framebuffer *fb = ctx->DrawBuffer;
> uint32_t surftype;
> unsigned int depth = 1;
> + unsigned int min_array_element;
> GLenum gl_target = GL_TEXTURE_2D;
> unsigned int lod;
> const struct intel_renderbuffer *irb = NULL;
> @@ -100,6 +101,15 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
>break;
> }
>
> + if (fb->MaxNumLayers > 0 || !irb) {
> + min_array_element = 0;
> + } else if (irb->mt->num_samples > 1) {
> + /* Convert physical layer to logical layer. */
> + min_array_element = irb->mt_layer / irb->mt->num_samples;
Above in gen6_blorp_emit_depth_stencil_config() you didn't try to adjust,
but here you do, why? In fact, checking the gen7 equivalent (patch a23cfb8),
I don't understand why the adjustment is done there either - even on gen7/8
both depth-msaa and stencil-msaa are still interleaved, right?
> + } else {
> + min_array_element = irb->mt_layer;
> + }
> +
> lod = irb ? irb->mt_level - irb->mt->first_level : 0;
>
> unsigned int len;
> --
> 2.0.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/17] i965: Split gen6 depth hiz state out from brw
On Fri, Jul 18, 2014 at 02:16:39PM -0700, Jordan Justen wrote:
> We will program the gen6 hiz depth state differently to enable layered
> rendering on gen6.
>
> v2:
> * Remove unneeded gen6_emit_depthbuffer as suggested by Topi
>
> Signed-off-by: Jordan Justen
Compared side by side with brw_emit_depth_stencil_hiz() and looks identical.
I was hoping we could start merging gen6-gen8 surface state logic as there
seems to be quite a bit of overlap. This change adds even more but I think
it is still a step forward as now gen6 is closer to gen7/8.
Proper refactoring between different generations requires some more thinking
and possibly some trial-and-error too. This patch will make that work easier
in my opinion.
Reviewed-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/Makefile.sources | 1 +
> src/mesa/drivers/dri/i965/brw_context.c | 2 +-
> src/mesa/drivers/dri/i965/brw_context.h | 10 ++
> src/mesa/drivers/dri/i965/gen6_depth_state.c | 176
> +++
> 4 files changed, 188 insertions(+), 1 deletion(-)
> create mode 100644 src/mesa/drivers/dri/i965/gen6_depth_state.c
>
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 43e3378..17256b6 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -122,6 +122,7 @@ i965_FILES = \
> gen6_blorp.cpp \
> gen6_cc.c \
> gen6_clip_state.c \
> + gen6_depth_state.c \
> gen6_depthstencil.c \
> gen6_gs_state.c \
> gen6_multisample_state.c \
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index dbe68a8..c7dfa87 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -648,7 +648,7 @@ brwCreateContext(gl_api api,
> } else if (brw->gen >= 6) {
>gen6_init_vtable_surface_functions(brw);
>gen4_init_vtable_sampler_functions(brw);
> - brw->vtbl.emit_depth_stencil_hiz = brw_emit_depth_stencil_hiz;
> + brw->vtbl.emit_depth_stencil_hiz = gen6_emit_depth_stencil_hiz;
> } else {
>gen4_init_vtable_surface_functions(brw);
>gen4_init_vtable_sampler_functions(brw);
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 2943a20..408939c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1751,6 +1751,16 @@ brw_emit_depth_stencil_hiz(struct brw_context *brw,
> uint32_t tile_x, uint32_t tile_y);
>
> void
> +gen6_emit_depth_stencil_hiz(struct brw_context *brw,
> +struct intel_mipmap_tree *depth_mt,
> +uint32_t depth_offset, uint32_t
> depthbuffer_format,
> +uint32_t depth_surface_type,
> +struct intel_mipmap_tree *stencil_mt,
> +bool hiz, bool separate_stencil,
> +uint32_t width, uint32_t height,
> +uint32_t tile_x, uint32_t tile_y);
> +
> +void
> gen7_emit_depth_stencil_hiz(struct brw_context *brw,
> struct intel_mipmap_tree *depth_mt,
> uint32_t depth_offset, uint32_t
> depthbuffer_format,
> diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> new file mode 100644
> index 000..d37aae8
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> @@ -0,0 +1,176 @@
> +/*
> + * Copyright (c) 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +
> +#include "intel_batchbuffer.h"
> +#include "intel_fbo.h"
> +#include "intel_mipmap_tree.h"
> +
Re: [Mesa-dev] [PATCH 02/17] i965/gen6: add support for layered renderbuffers
On Fri, Jul 18, 2014 at 02:16:37PM -0700, Jordan Justen wrote:
> Rather than pointing the surface_state directly at a single
> sub-image of the texture for rendering, we now point the
> surface_state at the top level of the texture, and configure
> the surface_state as needed based on this.
>
> v2:
> * Use SET_FIELD as suggested by Topi
> * Simplify min_array_element assignment as suggested by Topi
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/brw_defines.h| 4 ++
> src/mesa/drivers/dri/i965/gen6_surface_state.c | 76
> --
> 2 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 8b73c5c..fa39e4e 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -548,6 +548,10 @@
> /* Surface state DW4 */
> #define BRW_SURFACE_MIN_LOD_SHIFT28
> #define BRW_SURFACE_MIN_LOD_MASK INTEL_MASK(31, 28)
> +#define BRW_SURFACE_MIN_ARRAY_ELEMENT_SHIFT 17
> +#define BRW_SURFACE_MIN_ARRAY_ELEMENT_MASK INTEL_MASK(27, 17)
> +#define BRW_SURFACE_RENDER_TARGET_VIEW_EXTENT_SHIFT 8
> +#define BRW_SURFACE_RENDER_TARGET_VIEW_EXTENT_MASK INTEL_MASK(16, 8)
> #define BRW_SURFACE_MULTISAMPLECOUNT_1 (0 << 4)
> #define BRW_SURFACE_MULTISAMPLECOUNT_4 (2 << 4)
> #define GEN7_SURFACE_MULTISAMPLECOUNT_1 (0 << 3)
> diff --git a/src/mesa/drivers/dri/i965/gen6_surface_state.c
> b/src/mesa/drivers/dri/i965/gen6_surface_state.c
> index 9fec372..6fc8bdf 100644
> --- a/src/mesa/drivers/dri/i965/gen6_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_surface_state.c
> @@ -26,6 +26,7 @@
> #include "main/blend.h"
> #include "main/mtypes.h"
> #include "main/samplerobj.h"
> +#include "main/texformat.h"
> #include "program/prog_parameter.h"
>
> #include "intel_mipmap_tree.h"
> @@ -54,30 +55,17 @@ gen6_update_renderbuffer_surface(struct brw_context *brw,
> struct intel_renderbuffer *irb = intel_renderbuffer(rb);
> struct intel_mipmap_tree *mt = irb->mt;
> uint32_t *surf;
> - uint32_t tile_x, tile_y;
> uint32_t format = 0;
> /* _NEW_BUFFERS */
> mesa_format rb_format = _mesa_get_render_format(ctx,
> intel_rb_format(irb));
> + uint32_t surftype;
> + int depth = MAX2(rb->Depth, 1);
Both gen7 and gen8 set this based on intel_renderbuffer::layer_count, any
particular reason to use rb->Depth here (or are they always the same)?
With that clarified:
Reviewed-by: Topi Pohjolainen
> + GLenum gl_target = rb->TexImage ?
This could be declared as constant.
> + rb->TexImage->TexObject->Target : GL_TEXTURE_2D;
> +
> uint32_t surf_index =
>brw->wm.prog_data->binding_table.render_target_start + unit;
>
> - assert(!layered);
> -
> - if (rb->TexImage && !brw->has_surface_tile_offset) {
> - intel_renderbuffer_get_tile_offsets(irb, &tile_x, &tile_y);
> -
> - if (tile_x != 0 || tile_y != 0) {
> - /* Original gen4 hardware couldn't draw to a non-tile-aligned
> - * destination in a miptree unless you actually setup your renderbuffer
> - * as a miptree and used the fragile lod/array_index/etc. controls to
> - * select the image. So, instead, we just make a new single-level
> - * miptree and render into that.
> - */
> - intel_renderbuffer_move_to_temp(brw, irb, false);
> - mt = irb->mt;
> - }
> - }
> -
> intel_miptree_used_for_rendering(irb->mt);
>
> surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 6 * 4, 32,
> @@ -89,30 +77,38 @@ gen6_update_renderbuffer_surface(struct brw_context *brw,
> __FUNCTION__, _mesa_get_format_name(rb_format));
> }
>
> - surf[0] = (BRW_SURFACE_2D << BRW_SURFACE_TYPE_SHIFT |
> - format << BRW_SURFACE_FORMAT_SHIFT);
> + switch (gl_target) {
> + case GL_TEXTURE_CUBE_MAP_ARRAY:
> + case GL_TEXTURE_CUBE_MAP:
> + surftype = BRW_SURFACE_2D;
> + depth *= 6;
> + break;
> + default:
> + surftype = translate_tex_target(gl_target);
> + break;
> + }
> +
> + const int min_array_element = layered ? 0 : irb->mt_layer;
> +
> + surf[0] = SET_FIELD(surftype, BRW_SURFACE_TYPE) |
> + SET_FIELD(format, BRW_SURFACE_FORMAT);
>
> /* reloc */
> - surf[1] = (intel_renderbuffer_get_tile_offsets(irb, &tile_x, &tile_y) +
> - mt->bo->offset64);
> -
> - surf[2] = ((rb->Width - 1) << BRW_SURFACE_WIDTH_SHIFT |
> - (rb->Height - 1) << BRW_SURFACE_HEIGHT_SHIFT);
> -
> - surf[3] = (brw_get_surface_tiling_bits(mt->tiling) |
> - (mt->pitch - 1) << BRW_SURFACE_PITCH_SHIFT);
> -
> - surf[4] = brw_get_surface_num_multisamples(mt->num_samples);
> -
> - assert(brw->has_surface_tile_offset || (tile_x == 0 && tile_y == 0));
> - /* Note that the low bits of these fields are missing, so
> -* there's the possibility of getting in trouble.
> -*/
> - a
[Mesa-dev] [PATCH] [demos] fix direct rendering context in glxinfo
commit e769bc682b4a0d0f597286b067f54f923d159866 broke direct rendering
context because it defaults to indirect rendering and there is no way
to reverse it.
Signed-of-by: Marc Dietrich
---
src/xdemos/glinfo_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
index 95ef545..f536e98 100644
--- a/src/xdemos/glinfo_common.c
+++ b/src/xdemos/glinfo_common.c
@@ -747,7 +747,7 @@ parse_args(int argc, char *argv[], struct options *options)
options->limits = GL_FALSE;
options->singleLine = GL_FALSE;
options->displayName = NULL;
- options->allowDirect = GL_FALSE;
+ options->allowDirect = GL_TRUE;
for (i = 1; i < argc; i++) {
#ifndef _WIN32
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 00/14] i965/gen7+ hiz cleanup + gen8 hiz improvements
On Mon, Jul 21, 2014 at 11:00:49PM -0700, Jordan Justen wrote: > 1. No longer allocate a miptree structure for hiz on gen7+. > > 2. Always enable hiz for depth on gen8+. > > 3. Enable hiz Auxiliary Buffer support on gen8. This support allows >Broadwell to sample from depth using the hiz buffer, and thereby >removing the need to resolve depth to/from the hiz buffer in many >cases. > > v2: > * Modified hz_height calculation in patches 4 & 5 > > Patches without Reviewed-by: 4, 5, 6, 13 and 14 4-6 are: Reviewed-by: Topi Pohjolainen > > This series is available in the bdw-aux-hiz-v2 branch of: > git://people.freedesktop.org/~jljusten/mesa > > Jordan Justen (13): > i965/hiz: Start to separate miptree out from hiz buffers > i965/gen7: Don't rely directly on the hiz miptree structure > i965/gen8: Don't rely directly on the hiz miptree structure > i965/gen7: Don't allocate hiz miptree structure > i965/gen8: Don't allocate hiz miptree structure > i965/gen8: Enable hiz for all depth levels > i965: Wrap MCS miptree in intel_miptree_aux_buffer > i965/gen8: Use intel_miptree_aux_buffer for auxiliary buffer > i965/gen8: Use aux buf qpitch for Auxiliary Buffer (MCS) > i965: Add function to indicate when sampling with hiz is supported > i965: Support sampling with hiz during rendering > i965/gen8: Initialize aux_mode to GEN8_SURFACE_AUX_MODE_NONE > i965/gen8: Allow sampling with hiz when supported > > Kenneth Graunke (1): > i965/gen8: Add HiZ auxiliary buffer support > > src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +- > src/mesa/drivers/dri/i965/brw_draw.c | 5 +- > src/mesa/drivers/dri/i965/brw_misc_state.c| 4 +- > src/mesa/drivers/dri/i965/gen6_blorp.cpp | 2 +- > src/mesa/drivers/dri/i965/gen7_blorp.cpp | 10 +- > src/mesa/drivers/dri/i965/gen7_misc_state.c | 7 +- > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 8 +- > src/mesa/drivers/dri/i965/gen8_depth_state.c | 6 +- > src/mesa/drivers/dri/i965/gen8_surface_state.c| 45 +-- > src/mesa/drivers/dri/i965/intel_fbo.c | 4 +- > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 363 > ++ > src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 41 ++- > 12 files changed, 394 insertions(+), 103 deletions(-) > > -- > 2.0.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
