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 t
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
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95
> ++
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: Jor
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
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95
> ++
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 hi
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
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 91
> ++
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: Jo
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
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 on
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
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
On Thu, Jul 17, 2014 at 03:26:02PM -0700, Matt Turner wrote:
> Will
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 wrote:
> On 17.07.2014 21:00, Marek Olšák wrote:
>> On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> This is hopefully s
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
b/src/gallium/drivers/nouveau/codegen/nv50_ir_
Signed-off-by: Ilia Mirkin
---
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
--- a/src/gallium/drivers/nouveau/n
Signed-off-by: Ilia Mirkin
---
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.)
src/gallium/drivers/nouvea
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
Cc:
---
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.
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 +-
1 file
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 regist
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #12 from U. Artie Eoff ---
Created attachment 103044
--> https://bugs.freedesktop.org/attachment.cgi?id=103044&action=edit
clear color does not fill new viewport size
The problem is that the GL color buffer does not fill the GL vie
https://bugs.freedesktop.org/show_bug.cgi?id=68296
U. Artie Eoff changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
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 _mesa_drawbuffer
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 se
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
---
src/mesa/Makefile.sources| 1 +
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
---
src/mesa/main/texstore.c | 171 +++
1 f
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
---
src/mesa/main/format_pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
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
---
src/mesa/main/format_utils.c | 93
src/mesa/main/format_uti
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
---
src/mesa/main/texstore.c | 179 +++
1 file changed, 164 inser
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
---
src/mesa/main/texstore.c | 545 ++-
1 file changed, 66 insertions(+), 479 del
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #1 from Barto ---
Created attachment 103046
--> https://bugs.freedesktop.org/attachment.cgi?id=103046&action=edit
wrong color for the c172p plane, it's green instead of grey
--
You are receiving this mail because:
You are the assi
https://bugs.freedesktop.org/show_bug.cgi?id=81500
Kai changed:
What|Removed |Added
Attachment #103045|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #2 from Barto ---
Created attachment 103047
--> https://bugs.freedesktop.org/attachment.cgi?id=103047&action=edit
glxinfo for ati radeon hd4650 pcie
--
You are receiving this mail because:
You are the assignee for the bug.
___
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 m
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #3 from Kai ---
(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 because:
You are the assignee f
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: n
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 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
>> ---
>> src/mesa/main/f
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #4 from Barto ---
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,
because if I run flightgear (
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 s
On Fri, Jul 18, 2014 at 2:24 AM, Pohjolainen, Topi
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,
which might be better:
"
On Fri, Jul 18, 2014 at 8:32 AM, Brian Paul 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 that I have
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
---
I couldn't make a simple test-case that would cause the current logic to
fail. However when I did the same thing with doubles, I ran into tr
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #5 from Barto ---
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 driver for example ),
then
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 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 mantissa, and saves
> two
On Fri, Jul 18, 2014 at 5:47 PM, 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 GT
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 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 record anyway. The code
Signed-off-by: Vinson Lee
---
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() {
LLVM_REQUIRED_VERSION_MINOR="4"
LLVM
Reviewed-by: Marek Olšák
Marek
On Fri, Jul 18, 2014 at 9:15 PM, Vinson Lee wrote:
> Signed-off-by: Vinson Lee
> ---
> 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/
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 MAP_
---
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
+++ b/src/gal
---
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 1
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 insertions(+),
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 +
src/gallium/drivers/radeon/radeon_e
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
+++ b/
---
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 38ad077..41c1
---
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
b
On Fri, Jul 18, 2014 at 2:57 AM, Pohjolainen, Topi
wrote:
>
> 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 Pohjolaine
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
- EXT_framebuffer_multisample/multi
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
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80991
Cc: "10.2"
---
src/mesa/dr
On Fri, Jul 18, 2014 at 2:10 PM, Tom Stellard
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
> b/src/gallium/auxiliary/util/u_math.h
> index b
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #6 from Barto ---
I have started a bisect,
I use these settings :
git bisect start
git bisect bad a06c9791d1b7fcedfb56ecbdc601d42fab196916
git bisect good 5f41cae633af3603ab369c139bfe2de6bbcc6369
but when git wants me to test this
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #7 from Ilia Mirkin ---
(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 '_mesa_meta_begin'
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 GL_MA
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 1
On Fri, Jul 18, 2014 at 5:19 AM, Michel Dänzer wrote:
> On 17.07.2014 21:00, Marek Olšák wrote:
>> On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> This is hopefully safe: The kernel makes sure writes to these mappings
>>> finish before the GPU might start r
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 ++-
src/gallium/drivers/radeons
On Thu, Jul 17, 2014 at 8:04 PM, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> src/mesa/main/format_info.py | 11 +++
> src/mesa/main/formats.c | 46
>
> src/mesa/main/formats.h | 29
> 3
We will program the gen6 renderbuffer surface state differently to
enable layered rendering on gen6.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.c| 4 +
src/mesa/drivers/dr
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 mi
(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/m
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
---
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/dr
(08ef1dd for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
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 a/src/mesa/drivers/dri/i965/ge
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 assig
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
---
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/
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
git://pe
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
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 +++
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
---
src/mesa/drivers/dri/i965/intel_fbo.c | 3 ++-
src/mesa/drivers/dri/i965/intel_mipmap
(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 di
(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
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 2 ++
src/mesa/drivers/d
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
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.c | 2 +
(e3a49e1 for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
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
b/src/mesa/drivers/dri/i965/gen6_
On Fri, Jul 18, 2014 at 9:19 AM, Ilia Mirkin 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
> ---
>
> I couldn't make a simple test-case that would cause the current logic to
>
On Fri, Jul 18, 2014 at 1:19 PM, Kenneth Graunke 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
> - ARB_sample_shad
Reviewed-by: Matt Turner
___
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 wrote:
> On Fri, Jul 18, 2014 at 9:19 AM, Ilia Mirkin 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
>> ---
>>
>> I couldn't ma
On Fri, Jul 18, 2014 at 2:37 PM, Ilia Mirkin wrote:
> On Fri, Jul 18, 2014 at 5:27 PM, Matt Turner 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 abs(-2147483648) (which is likely -
On Fri, Jul 18, 2014 at 7:47 PM, Marek Olšák wrote:
> On Fri, Jul 18, 2014 at 5:47 PM, 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 stil
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #8 from Barto ---
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 bug in mesa 10.2.x,
it's
On Wed, Jul 16, 2014 at 4:14 PM, Thomas Helland
wrote:
> 2014-07-13 20:13 GMT+02:00 Matt Turner :
>>
>> On Sun, Jul 13, 2014 at 10:50 AM, Thomas Helland
>> wrote:
>> > I've considered writing an algebraic optimization to convert
>> > this into an ir_binop_pow. If my understanding is correct the b
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
wrote:
> Hi all,
>
> I've been looking at some shaders from Portal recently.
> A lot of them seem to hand-roll a pow-function with
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #9 from Barto ---
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 :
# only skipped commits left t
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 wrote:
> All Gallium drivers must support POW
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #10 from Barto ---
Created attachment 103066
--> https://bugs.freedesktop.org/attachment.cgi?id=103066&action=edit
bisect log, 12 commits who can be the guilty
the bisect log,
in fact there 12 commits who can be the guilty
The fi
1 - 100 of 123 matches
Mail list logo
