Piglit quick tests including sqrt pass, no other regressions,
tested on radeon 6670.
---
Should be slightly more precise than the invsqrt/recip/mul combination
used previously, I reckon up to about 2 bits of mantissa, and saves
two instructions per sqrt emitted.
It would be good if someone could
On Tue, Jul 15, 2014 at 06:32:12PM -0700, Jordan Justen wrote:
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
On Fri, Jul 18, 2014 at 11:02:56AM +0300, Pohjolainen, Topi wrote:
On Tue, Jul 15, 2014 at 06:32:12PM -0700, Jordan Justen wrote:
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
Signed-off-by: Jordan
On Tue, Jul 15, 2014 at 06:32:12PM -0700, Jordan Justen wrote:
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
On Fri, Jul 18, 2014 at 11:04:55AM +0300, Pohjolainen, Topi wrote:
On Fri, Jul 18, 2014 at 11:02:56AM +0300, Pohjolainen, Topi wrote:
On Tue, Jul 15, 2014 at 06:32:12PM -0700, Jordan Justen wrote:
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer
On Tue, Jul 15, 2014 at 06:32:13PM -0700, Jordan Justen wrote:
We now skip allocating a hiz miptree for gen8. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
On Tue, Jul 15, 2014 at 06:32:17PM -0700, Jordan Justen wrote:
For hiz, the qpitch may be different than the main miptree.
s/hiz/aux/ ?
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
On Tue, Jul 15, 2014 at 06:32:20PM -0700, Jordan Justen wrote:
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:
On 18/07/14 00:56, Eric Anholt wrote:
Here are the patches I have for common code in my vc4 driver tree. I
think they should be obvious enough.
I'm curious what people feel about merging vc4. I've got a series at this
point that's clean enough in my opinion (copyrights fixed up, and I
Pavel can you use up-to 80 column width for the commit message. It is somewhat
of a unwritten rule plus it makes things a bit easier to read :)
Cheers,
Emil
On 17/07/14 16:21, Pavel Popov wrote:
According to spec (OpenGL 4.0 specification, pages 254-255) we have a
different bits set
for one
On 18.07.2014 12:58, Dieter Nützel wrote:
Am 18.07.2014 05:07, schrieb Michel Dänzer:
On 17.07.2014 19:09, Christian König wrote:
Am 17.07.2014 12:01, 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
Subject of patch number four sort of hints that this would be used in patch
number three also. I didn't find any occurencies though, did you mean to use
it there already?
Anyway, patches 1-4 are:
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
On Thu, Jul 17, 2014 at 03:26:02PM -0700,
If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
patch is okay.
Marek
On Fri, Jul 18, 2014 at 5:19 AM, Michel Dänzer mic...@daenzer.net wrote:
On 17.07.2014 21:00, Marek Olšák wrote:
On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel
This code does nothing useful as the next recursive call on the array element
will override any null values if the element is a record anyway. The code is
also not doing what the comment says as its trying to set the record type
pointer for only the first element of the array not the first leaf
---
src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 +
src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index c624e21..ce0207a 100644
---
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I noticed this in a review of the code trying to figure out why the next
problem was happening. This doesn't actually fix anything, but there's no
reason why phi nodes must be restricted to 32-bit registers. (Although they
are, for now.)
Most of codegen is already FP64-ready. There are a few edge-cases that I ran
into, many of which can apply even to non-fp64-enabled programs (although the
double-wide registers are not very common without fp64).
I've yet to give this a full piglit run, but wanted to send these out in case
someone
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: mesa-sta...@lists.freedesktop.org
---
Was getting weird shader errors in dmat4*dmat4 which spilled one double-wide
register (i.e. size 8). envytools docs apparently list this as having to be
aligned to 0x10, and this indeed fixes it.
In a situation where double-register values are used, the phi nodes can
still end up being u32 values. They all get merged into one RA node
though. When fixing up the merge (which comes after the phi node), the
phi node's def would get fixed, but not its sources which would remain
at the low
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #12 from U. Artie Eoff ullysses.a.e...@intel.com ---
Created attachment 103044
-- https://bugs.freedesktop.org/attachment.cgi?id=103044action=edit
clear color does not fill new viewport size
The problem is that the GL color buffer
https://bugs.freedesktop.org/show_bug.cgi?id=68296
U. Artie Eoff ullysses.a.e...@intel.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
On 07/17/2014 09:21 AM, Pavel Popov wrote:
According to spec (OpenGL 4.0 specification, pages 254-255) we have a different
bits set
for one buffer and for multiple buffers. For glDrawBuffer we may have up to
four bits set
but for glDrawBuffers we can only have one bit set.
The
Currently mesa searches for two different environment variables,
LIBGL_DRIVERS_PATH and GBM_DRIVERS_PATH. The first is used for search
for DRI drivers in every case except GBM, and the latter is used
exclusively for setting GBM drivers. This patch simplifies things by
having just one variable to
Can you possibly shorten the subject/1st line of the commit message to
be 70-75 chars?
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
This initial commit puts all of the RGB - sRGB conversion functions in
one place.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
The first line of the commit msg should be shorter.
Why do you want to do this split? The commit message doesn't say.
-Brian
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 171
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
Before it was only storing one of the color components due to truncation.
With this patch it now properly stores all of them.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/format_pack.c | 2 +-
1 file changed, 1
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
Most format conversion operations required by GL can be performed by
converting one channel at a time, shuffling the channels around, and
optionally filling missing channels with zeros and ones. This adds a
function to do just that in a general, yet
Again, shorten the 1st line, please.
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
This is a direct helper function for using _mesa_swizzle_and_convert
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/format_utils.c | 93
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
This should be both faster and more accurate than our general slow-path of
converting everything to float.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 179 +++
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
Again, we delete a lot of functions that aren't really doing anything
interesting anymore.
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/texstore.c | 545 ++-
1 file changed,
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #1 from Barto mister.free...@laposte.net ---
Created attachment 103046
-- https://bugs.freedesktop.org/attachment.cgi?id=103046action=edit
wrong color for the c172p plane, it's green instead of grey
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=81500
Kai k...@dev.carbon-project.org changed:
What|Removed |Added
Attachment #103045|text/plain |image/png
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #2 from Barto mister.free...@laposte.net ---
Created attachment 103047
-- https://bugs.freedesktop.org/attachment.cgi?id=103047action=edit
glxinfo for ati radeon hd4650 pcie
--
You are receiving this mail because:
You are the
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
This is the first installment of some work I've been doing over the past
couple of weeks to refactor mesa's texture conversion/storage code. There
is more to be done and more that I have done but have not included in this
series. This is the first
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #3 from Kai k...@dev.carbon-project.org ---
(In reply to comment #0)
I can do an apitrace if you want it,
I'd guess doing a git bisect would be more helpful, since this sounds like a
regression.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=81500
Priority: medium
Bug ID: 81500
Assignee: mesa-dev@lists.freedesktop.org
Summary: wrong color in flightgear for the c172p if
Atmospheric light scattering is used
Severity:
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
On Fri, Jul 18, 2014 at 7:59 AM, Brian Paul bri...@vmware.com wrote:
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
Before it was only storing one of the color components due to truncation.
With this patch it now properly stores all of them.
Signed-off-by: Jason Ekstrand
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #4 from Barto mister.free...@laposte.net ---
I did an apitrace, I will post the link for download the file,
I will do a bisect also,
after tests I notice that it's probably a bug with the code related to the r600
driver in mesa,
Am 18.07.2014 05:07, schrieb Michel Dänzer:
On 17.07.2014 19:09, Christian König wrote:
Am 17.07.2014 12:01, schrieb Michel Dänzer:
In order to try and improve X(Shm)PutImage performance with glamor, I
implemented support for write-combined CPU mappings of BOs in GTT.
This did provide a nice
On Fri, Jul 18, 2014 at 2:24 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Tue, Jul 15, 2014 at 06:32:17PM -0700, Jordan Justen wrote:
For hiz, the qpitch may be different than the main miptree.
s/hiz/aux/ ?
The reason the change is needed is hiz. I could reword it like this,
On Fri, Jul 18, 2014 at 8:32 AM, Brian Paul bri...@vmware.com wrote:
On 07/17/2014 12:04 PM, Jason Ekstrand wrote:
This is the first installment of some work I've been doing over the past
couple of weeks to refactor mesa's texture conversion/storage code. There
is more to be done and more
The current code appears to work in simple tests, however this will
guarantee that the returned exponent is 0 for a 0 value.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I couldn't make a simple test-case that would cause the current logic to
fail. However when I did the same thing with
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #5 from Barto mister.free...@laposte.net ---
here is the apitrace :
http://demo.ovh.eu/download/365b2f85df30b16ec7539d7b9622542a/fgfs.tar.bz2
at start you will see a green aircraft if you graphic card is affected by the
bug ( r600
On Friday, July 18, 2014 07:41:57 AM Dylan Baker wrote:
Currently mesa searches for two different environment variables,
LIBGL_DRIVERS_PATH and GBM_DRIVERS_PATH. The first is used for search
for DRI drivers in every case except GBM, and the latter is used
exclusively for setting GBM drivers.
On Fri, Jul 18, 2014 at 3:54 AM, Glenn Kennard glenn.kenn...@gmail.com wrote:
Piglit quick tests including sqrt pass, no other regressions,
tested on radeon 6670.
---
Should be slightly more precise than the invsqrt/recip/mul combination
used previously, I reckon up to about 2 bits of
On Fri, Jul 18, 2014 at 5:47 PM, Christian König
deathsim...@vodafone.de 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
Please, every line of the commit message should be at most 80 characters long.
Marek
On Fri, Jul 18, 2014 at 1:47 PM, Timothy Arceri t_arc...@yahoo.com.au wrote:
This code does nothing useful as the next recursive call on the array element
will override any null values if the element is a
Signed-off-by: Vinson Lee v...@freedesktop.org
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index bdcc989..744e55c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1884,7 +1884,7 @@ radeon_llvm_check() {
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Fri, Jul 18, 2014 at 9:15 PM, Vinson Lee v...@freedesktop.org wrote:
Signed-off-by: Vinson Lee v...@freedesktop.org
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index
On 18.07.2014 13:45, Marek Olšák wrote:
If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
patch is okay.
Apart from correctness, I still wonder how this will affect performance,
most notably CPU reads. This change unconditionally uses write-combined,
uncached memory for
---
src/gallium/drivers/radeonsi/si_compute.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 3a9f00f..a7d61e7 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 6 ++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 576fea5..7cda70a
The scratch buffer will be used for private memory and also register
spilling.
---
src/gallium/drivers/radeonsi/si_compute.c | 85 ++-
src/gallium/drivers/radeonsi/si_shader.c | 5 ++
src/gallium/drivers/radeonsi/si_shader.h | 2 +
3 files changed, 90
The is used for programs that have arrays of constants that
are accessed using dynamic indices. The shader will compute
the base address of the constants and then access them using
SMRD instructions.
---
src/gallium/drivers/radeon/r600_pipe_common.h | 5 +
v2:
- Preserve word boundaries.
---
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..5de181a 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++
---
src/gallium/drivers/radeonsi/si_descriptors.c | 4 +---
src/gallium/drivers/radeonsi/si_shader.c | 8 +---
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index
---
src/gallium/drivers/r600/evergreen_compute.h | 13 -
src/gallium/drivers/radeon/r600_pipe_common.h | 5 +
src/gallium/drivers/radeonsi/si_compute.c | 5 +
3 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.h
We might be able to do this without an extra program key field, but this
is non-invasive and fixes the bug, for now.
This fixes the following Piglit tests on Broadwell:
- ARB_sample_shading/builtin-gl-sample-id 2
- ARB_sample_shading/builtin-gl-sample-position 2
-
We actually want to use mov(16), not mov(8).
Fixes 7 Piglit tests: ARB_sample_shading/builtin-gl-sample-mask [2468]
and ARB_sample_shading/builtin-gl-sample-mask-simple [468].
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80991
Cc:
On Fri, Jul 18, 2014 at 2:10 PM, Tom Stellard thomas.stell...@amd.com
wrote:
v2:
- Preserve word boundaries.
---
src/gallium/auxiliary/util/u_math.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_math.h
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #6 from Barto mister.free...@laposte.net ---
I have started a bisect,
I use these settings :
git bisect start
git bisect bad a06c9791d1b7fcedfb56ecbdc601d42fab196916
git bisect good 5f41cae633af3603ab369c139bfe2de6bbcc6369
but
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #7 from Ilia Mirkin imir...@alum.mit.edu ---
(In reply to comment #6)
I get an error during the compilation, it's impossible to build the commit
0939d3d0974a579fa65b76ebc6074d61e11f03b0 :
drivers/common/meta.c: In function
GL_MAP_READ_BIT is always unconditionally set for glBufferData, which
is the most-used function. However, st/mesa can look at the
immutability flag to distinguish between BufferData and BufferStorage
before pipe_buffer_create is called, and set the read flag if the
caller is BufferStorage and
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
On Fri, Jul 18, 2014 at 5:19 AM, Michel Dänzer mic...@daenzer.net wrote:
On 17.07.2014 21:00, Marek Olšák wrote:
On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
This is hopefully safe: The kernel makes sure writes to these
The scratch buffer will be used for private memory and also register
spilling.
v2:
- Code cleanups
---
I had some uncommitted changes left in my tree when I generated v1 of this
patch.
src/gallium/drivers/radeonsi/si_compute.c | 80 ++-
On Thu, Jul 17, 2014 at 8:04 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
src/mesa/main/format_info.py | 11 +++
src/mesa/main/formats.c | 46
src/mesa/main/formats.h
We will program the gen6 renderbuffer surface state differently to
enable layered rendering on gen6.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
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
(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 jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp
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
(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
b/src/mesa/drivers/dri/i965/intel_fbo.c
index e43e18b..22f707f 100644
(08ef1dd for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 3 +++
src/mesa/drivers/dri/i965/gen6_depth_state.c | 3 +++
2 files changed, 6 insertions(+)
diff --git
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
In the gen6 PRM Volume 1 Part 1: Graphics Core, Section
7.18.3.7.1 (Surface Arrays For all surfaces other than separate
stencil buffer):
[DevSNB] Errata: Sampler MSAA Qpitch will be 4 greater than the
value calculated in the equation above , for every other odd Surface
Height starting from 1
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.
(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 +++
src/mesa/drivers/dri/i965/gen6_depth_state.c | 10 ++
2 files changed, 13
The goal for this series was to allow layered rendering to work with
gen6. On gen6, it also fixes 10 failing piglit tests, 54 crashing
piglit tests, and a performance regression bug
(https://bugs.freedesktop.org/show_bug.cgi?id=56127).
This series is available on my gen6-layered branch in
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
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
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 10 +++-
src/mesa/drivers/dri/i965/gen6_depth_state.c
gen6 does not support multiple miplevels with separate
stencil/hiz. Therefore we need to layout its miptree with no mipmap
spacing between the slices of each miplevel.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/intel_fbo.c | 3 ++-
(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
(bc1acaa 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 jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp
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
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
(e3a49e1 for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
On Fri, Jul 18, 2014 at 9:19 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
The current code appears to work in simple tests, however this will
guarantee that the returned exponent is 0 for a 0 value.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I couldn't make a simple test-case that
On Fri, Jul 18, 2014 at 1:19 PM, Kenneth Graunke kenn...@whitecape.org wrote:
We might be able to do this without an extra program key field, but this
is non-invasive and fixes the bug, for now.
This fixes the following Piglit tests on Broadwell:
- ARB_sample_shading/builtin-gl-sample-id 2
-
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Jul 18, 2014 at 5:27 PM, Matt Turner matts...@gmail.com wrote:
On Fri, Jul 18, 2014 at 9:19 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
The current code appears to work in simple tests, however this will
guarantee that the returned exponent is 0 for a 0 value.
Signed-off-by: Ilia
On Fri, Jul 18, 2014 at 2:37 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Jul 18, 2014 at 5:27 PM, Matt Turner matts...@gmail.com wrote:
For 0.0f, applying the f2i and abs out of order doesn't affect the
result, but for -0.0f (0x8000, -2147483648) instead of getting 0,
you'd get
On Fri, Jul 18, 2014 at 7:47 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jul 18, 2014 at 5:47 PM, Christian König
deathsim...@vodafone.de 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
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #8 from Barto mister.free...@laposte.net ---
I have just realized that the last git version of mesa solves the bug :
Mesa 10.3.0-devel (git-f14d217)
but I will continue the bisect process in order to find the commit who triggers
the
On Wed, Jul 16, 2014 at 4:14 PM, Thomas Helland
thomashellan...@gmail.com wrote:
2014-07-13 20:13 GMT+02:00 Matt Turner matts...@gmail.com:
On Sun, Jul 13, 2014 at 10:50 AM, Thomas Helland
thomashellan...@gmail.com wrote:
I've considered writing an algebraic optimization to convert
this
All Gallium drivers must support POW, but some drivers like r300-r500
fragment shaders lower it to LG2+MUL+EX2.
Marek
On Sun, Jul 13, 2014 at 7:50 PM, Thomas Helland
thomashellan...@gmail.com wrote:
Hi all,
I've been looking at some shaders from Portal recently.
A lot of them seem to
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #9 from Barto mister.free...@laposte.net ---
I finished the bisect process,
because of the multiple commands git bisect skip the result of the bisect
process is complicated,
in fact there are 5 commits who can be the guilty :
#
BTW, I have just noticed r600g also lowers POW and there is no mention
of POW in the SI ISA guide either, so I don't think radeons would
benefit from an optimization pass that adds POW instructions.
Marek
On Sat, Jul 19, 2014 at 12:15 AM, Marek Olšák mar...@gmail.com wrote:
All Gallium drivers
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #10 from Barto mister.free...@laposte.net ---
Created attachment 103066
-- https://bugs.freedesktop.org/attachment.cgi?id=103066action=edit
bisect log, 12 commits who can be the guilty
the bisect log,
in fact there 12 commits who
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Fri, Jul 18, 2014 at 9:14 PM, Tom Stellard thomas.stell...@amd.com wrote:
---
src/gallium/drivers/r600/evergreen_compute.h | 13 -
src/gallium/drivers/radeon/r600_pipe_common.h | 5 +
1 - 100 of 122 matches
Mail list logo
