https://bugs.freedesktop.org/show_bug.cgi?id=88335
--- Comment #3 from Samuel Iglesias ---
I have access to a Mac OS X machine. The problem is not the output from Mako
template but the "indent" command in Mac OS X (likely the same in FreeBSD)
which is not the GNU one. That "indent" command is the
On 07.01.2015 10:10, Michel Dänzer wrote:
> On 07.01.2015 06:33, Tom Stellard wrote:
>> On Wed, Dec 24, 2014 at 12:48:31PM +0900, Michel Dänzer wrote:
>>> On 24.12.2014 02:49, Tom Stellard wrote:
Rather than building a new one every compile. This should reduce some
of the overhead of com
https://bugs.freedesktop.org/show_bug.cgi?id=88335
--- Comment #4 from Samuel Iglesias ---
Created attachment 112156
--> https://bugs.freedesktop.org/attachment.cgi?id=112156&action=edit
Patch
I wrote a patch that fixes the issue for Mac OS X but I have not access to a
FreeBSD machine.
Vinson
This is weird. We only enable this optimization if the shader code
doesn't use CENTROID at all. This is the main flag:
sctx->ps_shader->info.uses_centroid.
You can try to simplify the condition to:
bc_optimize_disable = sctx->ps_shader->info.uses_centroid;
That should avoid using the optimizatio
https://bugs.freedesktop.org/show_bug.cgi?id=88354
Eero Tamminen changed:
What|Removed |Added
CC||eero.t.tammi...@intel.com
--- Comment #1
I updated this patch as commented and it is now pending review again.
Thanks,
Eduardo
On 12/15/2014 11:30 AM, Eduardo Lima Mitev wrote:
> Per GLES3 specification, section 4.4 Framebuffer objects page 198, "If
> internalformat is a signed or unsigned integer format and samples is greater
> than z
This patch was updated and is pending review.
Thanks,
Eduardo
On 12/15/2014 11:47 AM, Eduardo Lima Mitev wrote:
> Section 4.2 (Whole Framebuffer Operations) of the OpenGL 3.0 specification
> says "Each buffer listed in bufs must be BACK, NONE, or one of the values from
> table 4.3 (NONE, COLOR_AT
https://bugs.freedesktop.org/show_bug.cgi?id=88369
Bug ID: 88369
Summary: Build break: generated format_*pack.c files are
accessed from wrong directory
Product: Mesa
Version: git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=88369
Samuel Iglesias changed:
What|Removed |Added
CC||sigles...@igalia.com
--- Comment #1 fr
Reviewed-by: Jason Ekstrand
On Jan 12, 2015 11:34 PM, "Iago Toral Quiroga" wrote:
> The suggests 8-bit components which is not correct, so
> replace that with the actual size of the components in each
> format.
> ---
> src/mesa/main/format_utils.c | 20 ++--
> src
https://bugs.freedesktop.org/show_bug.cgi?id=88369
Eero Tamminen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Jason Ekstrand writes:
> + _mesa_GenTextures(1, &pbo_tex);
> + pbo_tex_obj = _mesa_lookup_texture(ctx, pbo_tex);
> + pbo_tex_obj->Target = depth > 2 ? GL_TEXTURE_2D_ARRAY : GL_TEXTURE_2D;
Did you miss this? It still looks like it should be depth > 1.
Assuming you change that it looks good
This patch and the rest of the series (apart from the comment for patch
4) look good to me and are
Reviewed-by: Neil Roberts
- Neil
pgpBvaoeRSGjh.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fre
On 10/01/2015 14:27, David Heidelberg wrote :
I'd prefer not have to revert this patch on my personal r400 based
RS690 (laptop AMD X1250). You're correct, that most of applications
won't run.
Still, there are some earlier DX9 apps, which runs and LFS which shows
really visible performance boo
On Tue, Dec 09, 2014 at 03:39:26PM +0100, Luc Verhaegen wrote:
> On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
> > Hi,
> >
> > At FOSDEM on the 31st of january and the 1st of February 2015, there
> > will be another graphics DevRoom. URL: https://fosdem.org/2015/
>
> > Slots wil
On Tue, Jan 13, 2015 at 01:14:17PM +0100, Thierry Reding wrote:
> On Tue, Dec 09, 2014 at 03:39:26PM +0100, Luc Verhaegen wrote:
> > On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
> > > Hi,
> > >
> > > At FOSDEM on the 31st of january and the 1st of February 2015, there
> > > will
On 01/12/2015 12:27 PM, Adam Jackson wrote:
This just queries our context, it doesn't attempt to enumerate all the
available renderers.
Signed-off-by: Adam Jackson
---
src/xdemos/glxinfo.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/
On Tue, Jan 13, 2015 at 7:05 AM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
> > + _mesa_GenTextures(1, &pbo_tex);
> > + pbo_tex_obj = _mesa_lookup_texture(ctx, pbo_tex);
> > + pbo_tex_obj->Target = depth > 2 ? GL_TEXTURE_2D_ARRAY :
> GL_TEXTURE_2D;
>
> Did you miss this? It still looks
On Mon, Jan 12, 2015 at 9:54 PM, Tapani Pälli wrote:
> Patch enables ES2 extension that utilizes existing ES3 functionality.
>
> Changes make all the subtests to run and pass in WebGL conformance
> test 'webgl-draw-buffers' when running Chrome on OpenGL ES, also
> Piglit test 'draw_buffers_gles2'
https://bugs.freedesktop.org/show_bug.cgi?id=88335
--- Comment #5 from Vinson Lee ---
(In reply to Samuel Iglesias from comment #4)
>
> Vinson, Can you apply the patch and tell me if it fixes the issue in FreeBSD
> too? Once you confirmed that, I will send it to the mailing list.
>
attachment
On 01/12/2015 10:22 AM, Jason Ekstrand wrote:
> From: Sisinty Sasmita Patra
>
> This commit refactors the tiled_memcpy code in intel_tex_subimage.c and
> moves it into its own file intel_tiled_memcpy files. Also, xtile_copy and
> ytile_copy are renamed to linear_to_xtiled and linear_to_ytiled
>
This meta path, designed for use with PBO's, creates a temporary texture
out of the PBO and uses BlitFramebuffers to do the actual texture upload.
v2 Jason Ekstrand :
- Add support for handling simple packing options
v3 Jason Ekstrand :
- Refactor to split out the texture-from-pbo code
- Renam
Previously, we were completely ignoring the mt->offset field for
renderbuffers. While it does have some alignment constraints, it is valid
to use it. This patch adds the code to each of the 4 surface state setup
functions to handle it.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 3 ++
Going through the for loop every time has noticable overhead. This fixes
things up so we only do that once ever and then just do a hash table lookup
which should be much cheaper.
---
src/mesa/main/formats.c | 67 +
1 file changed, 56 insertions(+),
---
src/mesa/drivers/dri/i965/intel_tex_image.c | 203 +++-
1 file changed, 20 insertions(+), 183 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index b533dbd..58d675c 100644
--- a/src/mesa/drivers/dri/i
Since the meta path can do strictly more than the blitter path, we just
remove the blitter path entirely.
---
src/mesa/drivers/dri/i965/intel_pixel_read.c | 130 ++-
1 file changed, 6 insertions(+), 124 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
---
src/mesa/drivers/dri/i965/intel_tex.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_tex.c
b/src/mesa/drivers/dri/i965/intel_tex.c
index b2c0335..184702f 100644
--- a/src/mesa/drivers/dri/i965/intel_tex.c
+++ b/src/mesa
---
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 115 -
1 file changed, 15 insertions(+), 100 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_subimage.c
b/src/mesa/drivers/dri/i965/intel_tex_subimage.c
index 3e4ed1b..b96ad50 100644
--- a/src/mesa/drivers
---
src/mesa/drivers/common/meta.h | 8 ++
src/mesa/drivers/common/meta_tex_subimage.c | 117
2 files changed, 125 insertions(+)
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 8b70869..afe55d0 100644
--- a/src/mesa/dr
---
src/mesa/main/dd.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 2f40915..eb30847 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -415,6 +415,21 @@ struct dd_function_table {
struct gl
---
src/mesa/drivers/dri/i965/intel_fbo.c | 1 +
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 +++--
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 1 +
src/mesa/drivers/dri/i965/intel_pixel_draw.c | 2 +-
src/mesa/drivers/dri/i965/intel_pixel_read.c | 2 +-
src/mesa/drivers/dr
This series adds support for doing texture up/downloads using the render
pipeline instead of the blitter. There are a number of good reasons for
doing so.
1) The blitter is commonly thought to be slower than the render pipeline
in terms of its access to memory.
2) The blitter is on a diffe
On Tue, Jan 13, 2015 at 10:28 AM, Jason Ekstrand
wrote:
> This series adds support for doing texture up/downloads using the render
> pipeline instead of the blitter. There are a number of good reasons for
> doing so.
>
> 1) The blitter is commonly thought to be slower than the render pipeline
>
On Fri, Jan 9, 2015 at 5:21 PM, wrote:
> From: Mike Mason
>
> Changes the initial internal format of a render buffer
> to GL_RGBA4. This fixes a failure in the following
> DrawElements test:
>
> dEQP-GLES3.functional.state_query.rbo.renderbuffer_internal_format
> ---
> src/mesa/main/renderbuffe
Before we were always coping from the buffer being mapped into the
temporary buffer. However, if INVALIDATE_RANGE is set, then we know that
the data is going to be junk after we unmap so there's no point in doing
the blit. This is important because doing the blit will cause a stall 3
lines later
On 01/12/2015 10:22 AM, Jason Ekstrand wrote:
> From: Sisinty Sasmita Patra
>
> Added intel_readpixels_tiled_mempcpy and intel_gettexsubimage_tiled_mempcpy
> functions. These are the fast paths for glReadPixels and glGetTexImage.
>
> On chrome, using the RoboHornet 2D Canvas toDataURL test, this
On 01/09/2015 05:21 PM, michael.w.ma...@intel.com wrote:
> From: Mike Mason
>
> Changes the initial internal format of a render buffer
> to GL_RGBA4. This fixes a failure in the following
> DrawElements test:
>
> dEQP-GLES3.functional.state_query.rbo.renderbuffer_internal_format
> ---
> src/mes
On 01/12/2015 02:37 PM, michael.w.ma...@intel.com wrote:
> From: Mike Mason
>
> Removes commit 7894278 changes and moves fix to _mesa_GetInternalformativ().
> The original commit enabled the GL_RGB and GL_RGBA unsized internal formats
> as valid for render buffers in GLES3, but this is incorrect.
On Tue, Jan 13, 2015 at 06:47:00PM +0900, Michel Dänzer wrote:
> On 07.01.2015 10:10, Michel Dänzer wrote:
> > On 07.01.2015 06:33, Tom Stellard wrote:
> >> On Wed, Dec 24, 2014 at 12:48:31PM +0900, Michel Dänzer wrote:
> >>> On 24.12.2014 02:49, Tom Stellard wrote:
> Rather than building a ne
On Tue, Jan 13, 2015 at 10:49 AM, Chad Versace wrote:
> On 01/12/2015 02:37 PM, michael.w.ma...@intel.com wrote:
>> From: Mike Mason
>>
>> Removes commit 7894278 changes and moves fix to _mesa_GetInternalformativ().
>> The original commit enabled the GL_RGB and GL_RGBA unsized internal formats
>>
On 01/13/2015 11:12 AM, Matt Turner wrote:
> On Tue, Jan 13, 2015 at 10:49 AM, Chad Versace wrote:
>> On 01/12/2015 02:37 PM, michael.w.ma...@intel.com wrote:
>>> From: Mike Mason
>>>
>>> Removes commit 7894278 changes and moves fix to _mesa_GetInternalformativ().
>>> The original commit enabled
>>
>> Do we definitely need mako 0.7.3? RHEL6 only ships mako 0.3.4.
>>
>
> Can you test lowering the required Mako version in configure.ac?
>
> Search the following string: AX_CHECK_PYTHON_MAKO_MODULE
> and modify the version number that it receives as argument.
>
> I tested with Mako 0.3.6 (avail
On Thu, Jan 8, 2015 at 10:59 PM, Matt Turner wrote:
> total instructions in shared programs: 5886767 -> 5881642 (-0.09%)
> instructions in affected programs: 532199 -> 527074 (-0.96%)
> GAINED:9
> LOST: 6
> ---
And on Ironlake,
On Thu, Jan 8, 2015 at 10:59 PM, Matt Turner wrote:
> The pattern
>
>gl_FrontFacing ? -0.0 : -1.0
>
> appears in many shaders, but there's no significance of the 0.0's sign
> since it the result of the expression is always used in an addition.
>
> Getting the sign bit right would be an extra O
I would have no clue what this patch did if I just read the subject. How about:
> i965/fs: Allow constant propagation between different types.
Also, this should go in separately from NIR, since it affects things
(in Synmark) now:
instructions in affected programs: 2288 -> 2144 (-6.29%)
It a
On Tue, Jan 13, 2015 at 1:08 PM, Matt Turner wrote:
> I would have no clue what this patch did if I just read the subject. How
> about:
>
> > i965/fs: Allow constant propagation between different types.
>
Sure.
>
> Also, this should go in separately from NIR, since it affects things
> (in Synm
> -Original Message-
> From: Versace, Chad
> Sent: Tuesday, January 13, 2015 10:47 AM
> To: Mason, Michael W; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] mesa: Fix render buffer initial internal
> format type
>
> On 01/09/2015 05:21 PM, michael.w.ma...@intel.com wrote
Just use the negation source modifier on one of the multiplicand
arguments.
total instructions in shared programs: 5889529 -> 5880016 (-0.16%)
instructions in affected programs: 600846 -> 591333 (-1.58%)
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 12
1 file changed, 12 in
Just use the abs source modifier on both of the multiplicand
arguments.
instructions in affected programs: 300 -> 296 (-1.33%)
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw
On 01/13/2015 09:46 AM, Matt Turner wrote:
> On Mon, Jan 12, 2015 at 9:54 PM, Tapani Pälli wrote:
>> Patch enables ES2 extension that utilizes existing ES3 functionality.
>>
>> Changes make all the subtests to run and pass in WebGL conformance
>> test 'webgl-draw-buffers' when running Chrome on Op
On Tue, Jan 13, 2015 at 3:00 PM, Matt Turner wrote:
> Just use the negation source modifier on one of the multiplicand
> arguments.
>
> total instructions in shared programs: 5889529 -> 5880016 (-0.16%)
> instructions in affected programs: 600846 -> 591333 (-1.58%)
Reviewed-by: Kristian Høgsb
This is a fix for a regression introduced in commit a9f8296d ("i965/fs:
Preserve the CFG in a few more places.").
The errata this code works around is described in a comment before the function:
"[DevBW, DevCL] Errata: A destination register from a send can not be
used as a destination reg
Otherwise, we would have necessarily read the results or eliminated the
dead SEND. In either case, no work around is necessary.
Noticed when debugging the problem the previous patch fixed that any
time we hit a math instruction, we'd walk through subsequent
instructions, and of course each time di
On Tue, Jan 13, 2015 at 3:00 PM, Matt Turner wrote:
> Just use the abs source modifier on both of the multiplicand
> arguments.
>
> instructions in affected programs: 300 -> 296 (-1.33%)
Reviewed-by: Kristian Høgsberg
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 18 ++
On Tue, Jan 13, 2015 at 3:35 PM, Matt Turner wrote:
> Otherwise, we would have necessarily read the results or eliminated the
> dead SEND. In either case, no work around is necessary.
>
> Noticed when debugging the problem the previous patch fixed that any
> time we hit a math instruction, we'd wa
On 01/13/2015 02:34 PM, Mason, Michael W wrote:
>> -Original Message-
>> From: Versace, Chad
>> Sent: Tuesday, January 13, 2015 10:47 AM
>> To: Mason, Michael W; mesa-dev@lists.freedesktop.org
>> Subject: Re: [Mesa-dev] [PATCH] mesa: Fix render buffer initial internal
>> format type
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=88079
Chad Versace changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=86837
--- Comment #23 from Jose P. ---
Any news on this?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freed
> -Original Message-
> From: Versace, Chad
> Sent: Tuesday, January 13, 2015 3:42 PM
> To: Mason, Michael W; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] mesa: Fix render buffer initial internal
> format type
>
> On 01/13/2015 02:34 PM, Mason, Michael W wrote:
> >> ---
Brian and Ian, me and Michael have a Mesa TLS question at the message's bottom.
On 01/13/2015 04:41 PM, Mason, Michael W wrote:
>> -Original Message-
>> From: Versace, Chad
>> Sent: Tuesday, January 13, 2015 3:42 PM
>> To: Mason, Michael W; mesa-dev@lists.freedesktop.org
>> Subject: Re: [
On 12.01.2015 21:48, Jose Fonseca wrote:
> On 12/01/15 12:32, Iago Toral Quiroga wrote:
>> On lun, 2015-01-12 at 12:18 +, Jose Fonseca wrote:
>>>
>>> There seems to be some bad or missing dependency when building with
>>> automake. I have a build bot that roughly does this every time:
>>>
>>>
On 14.01.2015 04:07, Tom Stellard wrote:
> On Tue, Jan 13, 2015 at 06:47:00PM +0900, Michel Dänzer wrote:
>> On 07.01.2015 10:10, Michel Dänzer wrote:
>>> On 07.01.2015 06:33, Tom Stellard wrote:
On Wed, Dec 24, 2014 at 12:48:31PM +0900, Michel Dänzer wrote:
> On 24.12.2014 02:49, Tom Stel
https://bugs.freedesktop.org/show_bug.cgi?id=88354
--- Comment #2 from Seán de Búrca ---
I believe I'm using DRI2. My Xorg logs contain the following:
(II) GLX: Initialized DRI2 GL provider for screen 0
If this may be incorrect, please let me know. I am using xorg-server 1.16.2.901
and X Intel
On 13.01.2015 19:11, Marek Olšák wrote:
> This is weird. We only enable this optimization if the shader code
> doesn't use CENTROID at all. This is the main flag:
> sctx->ps_shader->info.uses_centroid.
>
> You can try to simplify the condition to:
>
> bc_optimize_disable = sctx->ps_shader->info.u
On Tuesday, January 13, 2015 10:39:22 AM Jason Ekstrand wrote:
> Before we were always coping from the buffer being mapped into the
> temporary buffer. However, if INVALIDATE_RANGE is set, then we know that
> the data is going to be junk after we unmap so there's no point in doing
> the blit. Thi
On Tuesday, January 13, 2015 10:28:20 AM Jason Ekstrand wrote:
> Going through the for loop every time has noticable overhead. This fixes
> things up so we only do that once ever and then just do a hash table lookup
> which should be much cheaper.
> ---
> src/mesa/main/formats.c | 67
> +
On Jan 13, 2015 6:38 PM, "Kenneth Graunke" wrote:
>
> On Tuesday, January 13, 2015 10:28:20 AM Jason Ekstrand wrote:
> > Going through the for loop every time has noticable overhead. This
fixes
> > things up so we only do that once ever and then just do a hash table
lookup
> > which should be muc
On Tuesday, January 13, 2015 08:02:54 PM Jason Ekstrand wrote:
> On Jan 13, 2015 6:38 PM, "Kenneth Graunke" wrote:
> >
> > On Tuesday, January 13, 2015 10:28:20 AM Jason Ekstrand wrote:
> > > Going through the for loop every time has noticable overhead. This
> fixes
> > > things up so we only do
On Tue, Jan 13, 2015 at 10:28 AM, Jason Ekstrand wrote:
> Going through the for loop every time has noticable overhead. This fixes
> things up so we only do that once ever and then just do a hash table lookup
> which should be much cheaper.
> ---
> src/mesa/main/formats.c | 67
> +++
Hi all,
Not sure how many of you have come across the webpage "Major Linux
Problems on the Desktop 2015 edition" [1]. Accurate or not it seems to
be getting a bit of attention. Anyway Mesa gets a bit of a bashing in
there although most of the information the author uses to backup their
claims are
On Tue, Jan 13, 2015 at 8:43 PM, Matt Turner wrote:
> On Tue, Jan 13, 2015 at 10:28 AM, Jason Ekstrand
> wrote:
> > Going through the for loop every time has noticable overhead. This fixes
> > things up so we only do that once ever and then just do a hash table
> lookup
> > which should be much
On Tue, Jan 13, 2015 at 9:45 PM, Jason Ekstrand wrote:
> On Tue, Jan 13, 2015 at 8:43 PM, Matt Turner wrote:
>> But, it sounded like what you wanted was for subsequent calls to
>> format_array_format_table_init() via call_once() to block until the
>> first had completed. I don't think call_once()
Hi;
On 12/15/2014 12:47 PM, Eduardo Lima Mitev wrote:
Section 4.2 (Whole Framebuffer Operations) of the OpenGL 3.0 specification
says "Each buffer listed in bufs must be BACK, NONE, or one of the values from
table 4.3 (NONE, COLOR_ATTACHMENTi)".
This patch adds this check before previous other,
On Tue, Jan 13, 2015 at 6:35 PM, Kenneth Graunke
wrote:
>
> On Tuesday, January 13, 2015 10:39:22 AM Jason Ekstrand wrote:
> > Before we were always coping from the buffer being mapped into the
> > temporary buffer. However, if INVALIDATE_RANGE is set, then we know
that
> > the data is going to b
A lot of messages hardcoded the string "FS", which is confusing on
Broadwell, where we use this code for VS support as well.
shader-db particularly got confused, as it reported two "FS SIMD8"
shaders, and no vertex shaders at all. Craziness ensued.
Signed-off-by: Kenneth Graunke
---
src/mesa/d
Signed-off-by: Samuel Iglesias Gonsalvez
Reviewed-by: Dave Airlie
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index d4cf4b8..3c614ea 100644
--- a/configure.ac
+++ b/configure.ac
@@ -76,7 +76,7 @@ if test "x$INDENT" != "xcat"; t
We were happily printing "Native code for unnamed vertex shader" and
"VS vec4" program for geometry shaders in our INTEL_DEBUG=gs output,
as well as the KHR_debug output used by shader-db.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.cpp| 2 +-
src/mesa/driv
Only GNU indent is supported when indenting autogenerated format_pack.c
and format_unpack.c files. Some non-GNU indent (Mac OS X and FreeBSD)
add extra whitespaces than break the build of those files.
Fallback to 'cat' if a non-GNU indent is found.
Fixes: https://bugs.freedesktop.org/show_bug.cgi
https://bugs.freedesktop.org/show_bug.cgi?id=88335
--- Comment #6 from Samuel Iglesias ---
Patch sent to the mailing list:
http://lists.freedesktop.org/archives/mesa-dev/2015-January/074367.html
--
You are receiving this mail because:
You are the assignee for the bug.
_
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Blits to or from a y-tiled surface must always be a multiple of the tile size.
From page 16 of the HSW PRM
(https://01.org/linuxgraphics/sites/default/files/documentation/intel-gfx-prm-osrc-hsw-memory-views.pdf#16)
"The pitch of a tiled enclosing region must be an integral number of tile
widths"
S
An upcoming patch is going to introduce some code here, and having this code
organized as the patch does makes it a bit easier to read later.
There should be no functional change here.
Signed-off-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/intel_blit.c | 28
1 fi
This patch will use a new calculation to determine if a surface can be blitted
from or to. Previously, the "total_height" member was used. Total_height in the
case of 2d, 3d, and cube map arrays is the height of each slice/layer/face.
Since the GL map APIS only ever deal with a slice at a time howe
The blit engine is limited to 32Kx32K transfer. In cases where we have to fall
back to the blitter, and when trying to blit a slice of a 2d texture array, or
face of a cube map, we don't need to transfer the entire texture.
I doubt this patch will get exercised at this point since we'll always all
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Jan 13, 2015 at 11:03 PM, Samuel Iglesias Gonsalvez
wrote:
> Only GNU indent is supported when indenting autogenerated format_pack.c
> and format_unpack.c files. Some non-GNU indent (Mac OS X and FreeBSD)
> add extra whitespaces than break the build of those files.
Seems like those indent
86 matches
Mail list logo
