We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
Currently it indicates that this is never supported, but soon it will
be supported for gen8+.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 ++
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c |
Today we allocate a miptree's for the hiz buffer. We needed this in
the past because we would point the hardware at offsets of the hiz
buffer. Since the hiz format is not documented, this is not a good
idea.
Since moving to support layered rendering on Gen7+, we no longer point
at an offset into
For gen8, we can sample from depth while using the hiz buffer. This
allows us to sample depth without resolving from hiz to the depth
texture.
To do this we must resolve to hiz before drawing so we can use the hiz
buffer to sample while rendering. Hopefully the hiz buffer will
already be resolved
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
GEN8_SURFACE_AUX_MODE_NONE is 0, so this is a no-op.
Yet, this also makes it clear that we can compare aux_mode to the
other GEN8_SURFACE_AUX_MODE_ values. We will want to compare to
GEN8_SURFACE_AUX_MODE_HIZ.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen
From: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
[jordan.l.jus...@intel.com: convert from aux_mt to aux_buf]
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 5 -
1 file changed, 4
For gen8+ this will indicate when we should allow hiz based sampling
during rendering.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
This will allow us to treat HiZ and MCS the same when using as an
auxiliary surface buffer.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +-
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
This will allow us to treat HiZ and MCS the same when using them as
auxiliary surface buffers.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 28 +-
1
For some auxiliary buffers the qpitch may be different than the main
miptree. (for example, hiz)
In i965: Wrap MCS miptree in intel_miptree_aux_buffer we set
aux_buf-qpitch to mt-qpitch, so for MCS, this should be a no-op.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi
We now skip allocating a hiz miptree for gen8. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c |
After modifying the hiz buffer allocation and qpitch calculation, hiz
appears to work in all cases on gen8.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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,
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 marvi...@gmx.de
---
src/xdemos/glinfo_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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:
*
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 jordan.l.jus...@intel.com
Compared side
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 jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 3 +++
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
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
Marek Olšák mar...@gmail.com 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
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
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 rsand...@linux.vnet.ibm.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
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,
...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 rsand...@linux.vnet.ibm.com
---
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
...i.e. formats in which the first listed component is in the least
significant half of the integer.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
---
src/gallium/include/pipe/p_format.h | 32
1 file changed, 32 insertions(+)
diff --git
On Fri, Jul 18, 2014 at 02:16:45PM -0700, Jordan Justen wrote:
(f3c886b for gen6)
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
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
https://bugs.freedesktop.org/show_bug.cgi?id=79949
drag...@gmail.com changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
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
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:
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
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 rsand...@linux.vnet.ibm.com
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c
...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 rsand...@linux.vnet.ibm.com
---
src/gallium/include/pipe/p_format.h | 24
1 file changed,
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 rsand...@linux.vnet.ibm.com
---
src/gallium/auxiliary/util/u_format.csv | 3 +++
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
The function was using the X component as the alpha channel,
rather than setting alpha to 1.0.
Signed-off-by: Richard Sandiford rsand...@linux.vnet.ibm.com
---
src/mesa/main/format_unpack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/format_unpack.c
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
https://bugs.freedesktop.org/show_bug.cgi?id=79949
--- Comment #10 from Joseph Booker j...@neoturbine.net ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=79949
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Am 22.07.2014 12:26, schrieb Richard Sandiford:
Roland Scheidegger srol...@vmware.com 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
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
On Tue, Jul 22, 2014 at 11:25 AM, Samuel Iglesias Gonsálvez
sigles...@igalia.com 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
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 rsand...@linux.vnet.ibm.com
On 07/21/2014 03:39 PM, Matt Turner wrote:
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
Just a few lines earlier we may have wrapped the index expression with
ir_unop_i2u expression. Whenever that happens, as_constant
On 07/21/2014 03:28 PM, Matt Turner wrote:
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
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
On 07/21/2014 03:35 PM, Matt Turner wrote:
On Mon, Jul 21, 2014 at 3:28 PM, Matt Turner matts...@gmail.com wrote:
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
Previously if a field of an block with an instance name was
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
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 jordan.l.jus...@intel.com
---
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
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
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
On 22/07/14 18:41, Giovanni Campagna wrote:
On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 21/07/14 17:02, Giovanni Campagna wrote:
On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Giovanni can you test the series that I've
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
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
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,
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
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
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
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
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
On Tue, Jul 22, 2014 at 3:10 PM, Neil Roberts n...@linux.intel.com 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 +
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Tue, Jul 22, 2014 at 11:43 AM, Dylan Baker baker.dyla...@gmail.com 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.
On Tue, Jul 22, 2014 at 11:43 AM, Dylan Baker baker.dyla...@gmail.com 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
Signed-off-by: Alon Levy al...@redhat.com
---
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
Signed-off-by: Alon Levy al...@redhat.com
---
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
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 al...@redhat.com
---
src/gallium/auxiliary/util/u_debug_flush.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
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)
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.
Remove incorrect struct prefix, ir_variable is a class
Signed-off-by: Alon Levy al...@redhat.com
---
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
Signed-off-by: Alon Levy al...@redhat.com
---
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
---
Signed-off-by: Alon Levy al...@redhat.com
---
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
On Tue, Jul 22, 2014 at 11:14 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com 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.
It appears Paul isn't working on this.
Signed-off-by: Dave Airlie airl...@redhat.com
---
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:
On Tue, Jul 22, 2014 at 3:09 PM, Neil Roberts n...@linux.intel.com 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's still started though -- there's a partial implementation in master.
On Wed, Jul 23, 2014 at 10:30 AM, Dave Airlie airl...@gmail.com wrote:
It appears Paul isn't working on this.
Signed-off-by: Dave Airlie airl...@redhat.com
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1
On Mon, Jul 21, 2014 at 5:29 PM, Matt Turner matts...@gmail.com wrote:
On Mon, Jul 21, 2014 at 5:16 PM, Jason Ekstrand ja...@jlekstrand.net
wrote:
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/imports.h | 4
1 file changed, 4 insertions(+)
diff --git
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
On Mon, Jul 21, 2014 at 9:54 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 21/07/14 17:02, Giovanni Campagna wrote:
On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
Giovanni can you test the series that I've not butchered anything else
during
the rebase
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
sigles...@igalia.com wrote:
Hello,
I have a doubt related to Streamed Vertex Buffer Write message and its
message descriptor in SandyBridge.
Reading about Stream
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 jason.ekstr...@intel.com
---
src/mesa/main/imports.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
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
87 matches
Mail list logo
