On Tue, Feb 26, 2013 at 12:28:14PM -0500, Kristian H?gsberg wrote:
> On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen
> wrote:
> > Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader
> > program with instructions that sample the separate Y- and U/V-planes
> > and convert the YUV to
On Tue, 26 Feb 2013 12:53:49 -0800
Chad Versace wrote:
> On 02/25/2013 11:58 PM, Pekka Paalanen wrote:
> > On Mon, 25 Feb 2013 09:09:22 -0800
> > Chad Versace wrote:
>
> > Thank you for the reply. Indeed, that dance to check for the extension
> > is non-trivial, and I think it might be good to
I want to reuse intel_miptree_map() to replace some region mapping that's
broken for separate stencil, but doing so would result in new demands on
ETC transcode that we actually don't want to happen.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |8
src/mesa/drivers/dri/intel/int
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp |3 +++
src/mesa/drivers/dri/i965/gen7_blorp.cpp |3 +++
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 3834ae2..2b6db82 100644
--- a/src/mesa/drivers/dri
Now that we have W-tiled S8, we can't just region_map and poke at bits --
there has to be some swizzling. Rely on intel_miptree_map to get that job
done. This should also get the highest performance path we know of for the
mapping (interesting if I get around to finishing movntdqa some day).
Fix
I have some debug of HiZ rendering that looks like some rendering is not
landing in my HiZ buffer. Unfortunately, fulsim choking on us violating
hiz rendering rules was preventing me from using it as a debug aid.
Once we get things reliable, we'll also be able to take advantage of this
to get fas
https://bugs.freedesktop.org/show_bug.cgi?id=61412
--- Comment #21 from James Ogden ---
(In reply to comment #20)
> Well if it's really a fallback, you could set a breakpoint in
> _mesa_meta_Bitmap and check what state is set which causes it right at the
> beginning of the function. Ideally there
From: Roland Scheidegger
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
The util code for handling clears also needs adjustments (and fix
a bug causing crashes for handling pure integer formats there too).
---
src/g
On 02/26/2013 10:16 AM, Andreas Boll wrote:
2013/2/26 Brian Paul:
OK, I have a git tree on fd.o with this patch series (plus updates to
intel_screen.c and configure.ac).
With your configure.ac patch API_DEFINES seems now unused.
But from what I can see src/gallium/targets/egl-static/egl_st.c u
https://bugs.freedesktop.org/show_bug.cgi?id=61412
--- Comment #20 from Roland Scheidegger ---
Well if it's really a fallback, you could set a breakpoint in _mesa_meta_Bitmap
and check what state is set which causes it right at the beginning of the
function. Ideally there wouldn't be any fallback
https://bugs.freedesktop.org/show_bug.cgi?id=61412
--- Comment #19 from James Ogden ---
I didn't think to check if GL_FOG was enabled at all during the rendering! I
know that I enabled it someplace for volumetric fog using glFogCoordf() which
is not available on this hardware (dunno why... my AM
https://bugs.freedesktop.org/show_bug.cgi?id=61527
--- Comment #1 from Andreas Boll ---
Until we find the cause of this issue
installing libtool should be a workaround.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa
---
src/gallium/drivers/r600/evergreen_state.c |5 +
src/gallium/drivers/r600/r600.h |1 +
src/gallium/drivers/r600/r600_hw_context.c |8
src/gallium/drivers/r600/r600_hw_context_priv.h |2 +-
src/gallium/drivers/r600/r600_state.c |
This doesn't fix any issue we know of, but there indeed is a week spot
in draw_vbo where streamout can fail. After streamout is enabled,
the need_cs_space call can flush the context, which causes the streamout
to be disabled right after it was enabled and bad things happen.
One way to fix it is to
probably a typo
---
src/gallium/drivers/r600/r600_buffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index 9f8f739..8b2f505 100644
--- a/src/gallium/drivers/r600/r600_buffer.c
+++ b/src/ga
It does not work with TF2.
NOTE: This is a candidate for the 9.1 branch.
---
src/gallium/drivers/r600/r600_buffer.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/r600/r600_buffer.c
b/src/gallium/drivers/r600/r600_buffer.c
index e0ac047..9f8f739 100644
--- a/src/galli
also don't require dword alignment with CP DMA for buffer transfers, which
is a leftover from the days when we used streamout to copy buffers
NOTE: This is a candidate for the 9.1 branch.
---
src/gallium/drivers/r600/r600_blit.c |3 +--
src/gallium/drivers/r600/r600_buffer.c |7
https://bugs.freedesktop.org/show_bug.cgi?id=61364
John Kåre Alsaker changed:
What|Removed |Added
Version|git |9.1
--
You are receiving this mail
On Tue, Feb 26, 2013 at 12:53 PM, Andreas Boll
wrote:
> 2013/2/25 Matt Turner :
>> And don't build it from other Makefiles. That's awful, and breaks
>> distclean.
>> ---
>> configure.ac |8
>> src/gallium/targets/opencl/Makefile.am |3 ---
>> src/gallium
On 02/26/2013 06:23 AM, Jakob Bornecrantz wrote:
> [SNIP]
>
>>> Hi,
>>>
>>> is it possible to build a binary, that will use this extension if it is
>>> present in whatever libEGL is available at runtime, and if it is not,
>>> fall back gracefully to using the core eglGetDisplay()?
>>>
>>> Or is th
Other than the two comments in patch 6 and 8 this series is
Reviewed-by: Andreas Boll
I'll test it with various configs tomorrow.
2013/2/25 Matt Turner :
> ---
> configure.ac | 38 +-
> src/gallium/winsys/Makefile.am| 62
> ++
On 02/25/2013 11:58 PM, Pekka Paalanen wrote:
> On Mon, 25 Feb 2013 09:09:22 -0800
> Chad Versace wrote:
> Thank you for the reply. Indeed, that dance to check for the extension
> is non-trivial, and I think it might be good to explain somehow in the
> spec, maybe in the Q&A section?
Yes, I'll a
2013/2/25 Matt Turner :
> And don't build it from other Makefiles. That's awful, and breaks
> distclean.
> ---
> configure.ac |8
> src/gallium/targets/opencl/Makefile.am |3 ---
> src/gallium/tests/trivial/Makefile.am |7 ---
> 3 files changed,
Any reason you don't keep using the Makefile.am in src/gallium/state_trackers/
as you did in patch 9 and 10?
2013/2/25 Matt Turner :
> configure still uses it to print the enabled state trackers.
> ---
> Makefile.am| 51
> +++-
> configur
https://bugs.freedesktop.org/show_bug.cgi?id=61527
Andreas Boll changed:
What|Removed |Added
Version|9.0 |9.1
--
You are receiving this mail becau
On 02/26/2013 11:58 AM, Jordan Justen wrote:
On Tue, Feb 26, 2013 at 10:16 AM, Brian Paul wrote:
On 02/26/2013 10:09 AM, Jordan Justen wrote:
On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote:
This series removes the dependencies on the mfeatures.h file and the file
itself.
I'd appreciat
https://bugs.freedesktop.org/show_bug.cgi?id=61527
Priority: medium
Bug ID: 61527
Assignee: mesa-dev@lists.freedesktop.org
Summary: MesaLib-9.1: Does not build. LIBTOOL not defined for
some makefiles
Severity: normal
Cla
On Tue, Feb 26, 2013 at 1:05 PM, Stefan Seifert wrote:
> Good news!
>
> I gave the r600-sb branch a good testing at commit
> 265ae41b1f1d086d35d274c7378c43cddb8215c8 and so far I've not had a single
> lockup in about 1 1/2 hours of flight time!
>
> The downside is that this is with R600_HYPERZ=0.
On Tue, Feb 26, 2013 at 10:16 AM, Brian Paul wrote:
> On 02/26/2013 10:09 AM, Jordan Justen wrote:
>>
>> On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote:
>>>
>>> This series removes the dependencies on the mfeatures.h file and the file
>>> itself.
>>>
>>> I'd appreciated someone doing a test bu
On 02/26/2013 10:49 PM, Benjamin Bellec wrote:
Hello,
Does your branch should works on R700 ?
I tested it on a RV770 but get many corruptions on Counter Strike Source
(native). I haven't tested anything else.
There are still some known problems with r7xx chips, hopefully they'll
be fixed soo
Hello,
Does your branch should works on R700 ?
I tested it on a RV770 but get many corruptions on Counter Strike Source
(native). I haven't tested anything else.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailm
https://bugs.freedesktop.org/show_bug.cgi?id=49777
--- Comment #1 from Arkadiusz Miskiewicz ---
For 9.1 the result is much better:
Searching for shared objects with unresolved symbols...
Unresolved symbols found in:
/home/users/arekm/tmp/Mesa-9.1-root-arekm/usr/lib64/libGLESv1_CM.so.1.1.0
On 02/25/2013 06:48 PM, Brian Paul wrote:
On 02/25/2013 06:57 PM, Ian Romanick wrote:
On 02/25/2013 05:17 PM, Brian Paul wrote:
On 02/25/2013 11:10 AM, Jordan Justen wrote:
Reviewed-by: Jordan Justen
On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote:
This series removes the dependencies on t
Ian Romanick writes:
> On 02/22/2013 07:52 PM, Eric Anholt wrote:
>> ---
>> src/mesa/main/errors.c | 38 +++---
>> 1 file changed, 3 insertions(+), 35 deletions(-)
>>
>> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
>> index 761b555..987cddb 100
On 02/19/2013 05:03 PM, Matt Turner wrote:
---
src/glsl/opt_algebraic.cpp | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 75948db..952941e 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/gl
On 02/26/2013 09:51 AM, Kenneth Graunke wrote:
On 02/19/2013 05:03 PM, Matt Turner wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 9ab18cc..6965d72 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/
On 02/26/2013 10:09 AM, Jordan Justen wrote:
On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote:
This series removes the dependencies on the mfeatures.h file and the file
itself.
I'd appreciated someone doing a test build of this series to double-check my
work.
I'm getting a build error:
G
Good news!
I gave the r600-sb branch a good testing at commit
265ae41b1f1d086d35d274c7378c43cddb8215c8 and so far I've not had a single
lockup in about 1 1/2 hours of flight time!
The downside is that this is with R600_HYPERZ=0. But with HYPERZ enabled, I
get lockups on master as well, so it w
On 02/19/2013 05:03 PM, Matt Turner wrote:
From: Kenneth Graunke
Previously, we had separate constructors for one, two, and four operand
expressions. This patch consolidates them into a single constructor
which uses NULL default parameters.
The unary and binary operator constructors had asser
On 02/19/2013 05:03 PM, Matt Turner wrote:
From: Kenneth Graunke
v2 [mattst88]:
- Add BRW_OPCODE_LRP to list of CSE-able expressions.
- Fix op_var[] array size.
- Rename arguments to emit_lrp to (x, y, a) to clear confusion.
- Add LRP function to brw_fs.cpp/.h.
- Corrected c
On 02/19/2013 05:03 PM, Matt Turner wrote:
---
src/glsl/opt_algebraic.cpp | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index 75948db..952941e 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/gl
Same error here.
Configuration: ./autogen.sh --enable-texture-float --enable-opencl
--with-gallium-drivers=r600 --with-dri-drivers=radeon --prefix=/usr/local
--Aaron
On Tue, Feb 26, 2013 at 11:09 AM, Jordan Justen wrote:
> On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote:
> > This series re
On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen
wrote:
> Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader
> program with instructions that sample the separate Y- and U/V-planes
> and convert the YUV to RGB as specified by ITU-R BT.601. Packed
> formats are handled through the n
2013/2/26 Brian Paul :
> OK, I have a git tree on fd.o with this patch series (plus updates to
> intel_screen.c and configure.ac).
With your configure.ac patch API_DEFINES seems now unused.
But from what I can see src/gallium/targets/egl-static/egl_st.c used
it to define FEATURE_{GL,ES1,ES2}
>
>
On Tue, Feb 26, 2013 at 8:19 AM, Topi Pohjolainen
wrote:
> Signed-off-by: Topi Pohjolainen
> ---
> include/GL/internal/dri_interface.h |1 +
> src/mesa/drivers/dri/intel/intel_screen.c |5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/include/GL/internal/dri_interface.h
On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul wrote:
> This series removes the dependencies on the mfeatures.h file and the file
> itself.
>
> I'd appreciated someone doing a test build of this series to double-check my
> work.
I'm getting a build error:
GENmain/get_hash.h
updating main/git_s
https://bugs.freedesktop.org/show_bug.cgi?id=61412
--- Comment #18 from Roland Scheidegger ---
FWIW if it's glBitmap causing this due to sw fallback, it will be much worse on
old radeons (r100/r200), due to sw fallback being way worse there.
There's still a couple of other bugs filed due to that
OK, I have a git tree on fd.o with this patch series (plus updates to
intel_screen.c and configure.ac).
git clone git://people.freedesktop.org/~brianp/mesa.git
git check-out -b remove-mfeatures remotes/origin/remove-mfeatures
-Brian
___
mesa-dev maili
On 02/26/2013 02:10 AM, Chris Forbes wrote:
This series adds the core mesa bits for ARB_texture_multisample, and support
in the i965 driver for Gen6 and Gen7.
I've addressed the issues that were raised for V3, and also fixed some other
bugs which I found while beefing up the piglit coverage for
On 02/26/2013 02:10 AM, Chris Forbes wrote:
V2: - fix formatting issues
- generate GL_OUT_OF_MEMORY if teximage cannot be allocated
- fix for state moving from texobj to image
V3: - remove ridiculous stencil hack
- alter format check to not allow a base format of STENCIL_INDEX
Reviewed-by: Marek Olšák
Marek
On Tue, Feb 26, 2013 at 4:20 PM, Brian Paul wrote:
> Just use simple assignments.
> ---
> src/mesa/state_tracker/st_atom_rasterizer.c | 23 ---
> 1 files changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_at
Hi Topi,
> The second more or less questionable part is the support for creating YUV
> buffers. In order to test for YUV sampling one needs a way of providing them
> for the EGL stack. Here I chose to augment the dri driver backing gbm as I
> couldn't come up with anything better. It may be helpfu
On 02/26/2013 08:49 AM, Ian Romanick wrote:
On 02/26/2013 07:43 AM, Brian Paul wrote:
On 02/25/2013 08:34 PM, Matt Turner wrote:
> On Mon, Feb 25, 2013 at 6:48 PM, Brian Paul wrote:
>> I've never setup a git repo for my home fdo.o account. To be
honest, I'd
>> have to do some digging around to
On 02/26/2013 07:43 AM, Brian Paul wrote:
On 02/25/2013 08:34 PM, Matt Turner wrote:
> On Mon, Feb 25, 2013 at 6:48 PM, Brian Paul wrote:
>> I've never setup a git repo for my home fdo.o account. To be
honest, I'd
>> have to do some digging around to figure that out.
>
> In fact it's a pr
On 02/25/2013 08:34 PM, Matt Turner wrote:
> On Mon, Feb 25, 2013 at 6:48 PM, Brian Paul wrote:
>> I've never setup a git repo for my home fdo.o account. To be
honest, I'd
>> have to do some digging around to figure that out.
>
> In fact it's a pretty easy process. See
> http://www.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=61395
--- Comment #5 from Blaž Hrastnik ---
Ah yes, apparently it was in the "ati-dri" package that arch built. Works
properly now, thanks! By the way, I have some more unresolved bugs (Regarding
OpenGL 1.x-2.1) on a opengl ruby binding library
(https:
Just use simple assignments.
---
src/mesa/state_tracker/st_atom_rasterizer.c | 23 ---
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_rasterizer.c
b/src/mesa/state_tracker/st_atom_rasterizer.c
index 7fdfa72..0e2a152 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=61395
--- Comment #4 from Blaž Hrastnik ---
Hmm, I probably rebuilt it incorrectly, I used ArchLinux's PKGBUILD file to
auto build it into a package (and apply the patch beforehand), the build system
probably splits these packages differently (I ended
On 02/26/2013 08:05 AM, Paul Berry wrote:
On 26 February 2013 01:47, Madan Mohan Chinnam
mailto:madan_chin...@infosys.com>> wrote:
Hi,
I am trying to use "normalize" method at fragment test shader in
my Open GL es2 application.
precision mediump float;
varying vec4 color;
https://bugs.freedesktop.org/show_bug.cgi?id=61395
--- Comment #3 from Brian Paul ---
Hmm, I retested here and it works. Are you sure everything was rebuilt
properly? The get_hash.h file gets regenerated from the get_hash_params.py
file (which is what we're patching). Could you try rm'ing get_
On Tue, Feb 26, 2013 at 3:16 PM, Alex Deucher wrote:
> On Tue, Feb 26, 2013 at 5:24 AM, Marek Olšák wrote:
>> I've tested CP DMA and it's better than it was, unfortunately it's on
>> par with R700, which means that piglit passes and Team Fortress 2 has
>> a corrupted GUI. At this point I think it
Great, I'll do some testing again when I get the chance.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 26 February 2013 01:47, Madan Mohan Chinnam wrote:
> Hi,
>
> I am trying to use "normalize" method at fragment test shader in my Open
> GL es2 application.
>
> precision mediump float;
> varying vec4 color;
>
> void main (void)
> {
> vec4 tmp_Color = color + vec4(0.25);
> gl_FragColor =
Hi,
I am trying to use "normalize" method at fragment test shader in my Open GL es2
application.
precision mediump float;
varying vec4 color;
void main (void)
{
vec4 tmp_Color = color + vec4(0.25);
gl_FragColor = vec4(normalize(tmp_Color.r), 0.0, 0.0, 1.0);
}
With above shader, my app
Thank you very much for this reply Matt.
I have been giving this a go and managed to clear most of it except the LLVM,
which I am having trouble cross-compiling.
I have sent an email on their list and waiting for a respond.
regards
Einar
From: Matt Tur
[SNIP]
>> Hi,
>>
>> is it possible to build a binary, that will use this extension if it is
>> present in whatever libEGL is available at runtime, and if it is not,
>> fall back gracefully to using the core eglGetDisplay()?
>>
>> Or is this specifically not supported, since I cannot see a way for
On Tue, Feb 26, 2013 at 5:24 AM, Marek Olšák wrote:
> I've tested CP DMA and it's better than it was, unfortunately it's on
> par with R700, which means that piglit passes and Team Fortress 2 has
> a corrupted GUI. At this point I think it would be better to disable
> the CP DMA for R600-R700 and
On 02/24/2013 11:01 PM, Henri Verbeet wrote:
On 24 February 2013 17:07, Vadim Girlin wrote:
If you'd like to help me with debugging the issues on cayman, then please
read the "regression debugging" section in the r600-sb branch notes [1] (or
possibly more up-to-date source here - [2]), it expla
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index bf5e2b5..33763e2 100755
--- a/src/mesa/drivers/dri/intel/in
Namely YUV420, YVU420 (YV12) and NV12. Here one extends the shader
program with instructions that sample the separate Y- and U/V-planes
and convert the YUV to RGB as specified by ITU-R BT.601. Packed
formats are handled through the normal paths.
Here is only support for fragment shaders for now. I'
Specifically YUV420, YVU420 (YV12) and NV12 formatted. The logic is
pretty much taken from Kristian Hogsberg [1]. All the planes are
back-to-back but each starts at page boundary. Horizontal and
vertical alignment are set according to sampling engine constraints.
This is to serve piglit testing of
Signed-off-by: Topi Pohjolainen
---
include/GL/internal/dri_interface.h |1 +
src/mesa/drivers/dri/intel/intel_screen.c |5 +
2 files changed, 6 insertions(+)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 42147e9..b06bc4a 100644
-
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_screen.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 277b133..5040992 100644
--- a/sr
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 36 +
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 36 +
2 files changed, 72 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/s
This prepares for image external textures having multiple planes
and hence calling for one to set up more than one surface per
texture.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 90 ---
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |4 ++--
src/mesa/drivers/dri/intel/intel_mipmap_tree.h |2 +-
src/mesa/drivers/dri/intel/intel_regions.c |2 +-
src/mesa/drivers/dri/intel/intel_regions.h |2 +-
4 files changed, 5 insertio
Both sampling and possible conversion to RGB are dependent on the
format of the DRI image representing the pixel source. In order to
accomodate this one re-compiles the program upon any changes.
Altering the program key effectively kicks off the re-compilation
as part of brw state uploading.
Sign
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_vs.c | 22 +
src/mesa/drivers/dri/i965/brw_wm.c | 25 +++-
src/mesa/drivers/dri/intel/intel_tex_obj.h | 29
3 files changed, 67 insertions(+
One needs to check here if the shader compiler backend is capable of
producing the extra instructions for the given format. One is not
allowed to fail in the code generation phase anymore and it is
probably better from the shader author point of view also to know as
soon as possible.
Signed-off-by
In preparation for supporting external image textures consisting of
multiple planes (YUV).
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_context.h | 12 ++--
src/mesa/drivers/dri/i965/brw_vs.c | 16
src/mesa/drivers/dri/i965
In preparation for supporting external image textures consisting of
multiple planes (YUV). One now reserves entries in the sampling engine
surface state table only for those samplers that are really used in the
current program using a binding table associating a sampler with a slot
in the state tab
The series adds support for i965 driver to sample YUV420, NV12 and YV12
formatted buffers originating outside the GL-stack. There is only support for
the fragment shaders for now (even though one prepares for vertex shaders also).
In a summary, the relation between a mesa core maintained sampler a
https://bugs.freedesktop.org/show_bug.cgi?id=61415
--- Comment #5 from Francisco Jerez ---
(In reply to comment #4)
> Out of interest what are the auxiliary libraries? As I'm not getting
> anything in that directory
You should be getting a .so file for each pipe driver you're building.
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=61395
--- Comment #2 from Blaž Hrastnik ---
The proposed patch does not work for me, it still returns true.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing lis
I've tested CP DMA and it's better than it was, unfortunately it's on
par with R700, which means that piglit passes and Team Fortress 2 has
a corrupted GUI. At this point I think it would be better to disable
the CP DMA for R600-R700 and use streamout or async DMA instead.
Marek
On Fri, Feb 22, 2
V2: Works on Ivy Bridge now too, so this can be 6+.
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
Reviewed-by: Eric Anholt
---
src/mesa/drivers/dri/intel/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drive
On Gen6, lower this to `ld` with lod=0 and an extra sample_index
parameter.
On Gen7, use `ld2dms`. We don't support CMS yet for multisample
textures, so we just hardcode MCS=0. This is ignored for IMS and UMS
surfaces.
Note: If we do end up emitting specialized shaders based on the MSAA
layout, w
On Gen6, lower this to `ld` with lod=0 and an extra sample_index
parameter.
On Gen7, use `ld2dms`. This takes an additional MCS parameter to support
compressed multisample surfaces, but we're not enabling them for
multisample textures for now, so it's always ignored and can be safely
omitted.
V2:
This is very similar to the TXF opcode, but lowers to `ld2dms` rather
than `ld` on Gen7.
V4: - add SHADER_OPCODE_TXF_MS to is_tex() functions, so regalloc thinks
it actually writes the correct number of registers. Otherwise in
nontrivial shaders some of the registers tend to get clobbe
Gen7 has an erratum affecting the ld_mcs message, making it unsafe to
use when the surface doesn't have an associated MCS.
>From the Ivy Bridge PRM, Vol4 Part1 p77 ("MCS Enable"):
"If this field is disabled and the sampling engine
message is issued on this surface, the MCS surface may be
The surface_state setup for renderbuffers already worked; only the
texturing side needed work. BLORP does something similar, but does its
own surface_state setup.
On Gen6, we just need to set the correct sample count.
On Gen7: - set the correct sample count
- set the correct layout mode
V2: - Fix for state moving from texobj to image
- Rebased onto Paul's logical/physical cleanup
- Fixed missing quantization of sample count
- Fold in IMS renderbuffer wrapper fixes from later in the series
- Use correct physical slice offset for UMS/CMS surfaces on Gen7
Signed-off-
V2: - fix formatting issues
- generate GL_OUT_OF_MEMORY if teximage cannot be allocated
- fix for state moving from texobj to image
V3: - remove ridiculous stencil hack
- alter format check to not allow a base format of STENCIL_INDEX
- allow width/height/depth to be zero, to deallo
- sample count must be the same on all attachments
- fixedsamplepositions must be the same on all attachments
(renderbuffers have fixedsamplepositions=true implicitly; only
multisample textures can choose to have it false)
V2: - fix wrapping to 80 columns, debug message, fix for state moving
Moves the definition of the sample positions out of
gen6_emit_3dstate_multisample, and unpacks them in
gen6_get_sample_position.
V2: Be consistent about `sample position` rather than `location`.
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_context.c
Signed-off-by: Chris Forbes
Reviewed-by: Eric Anholt
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_context.h| 2 +-
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/gen6_multisample_state.c | 19 +--
src/mesa/drivers/
V2: - fix multiline comment style
- stop using ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH since that
doesn't exist anymore.
V3: - check for the extension being enabled
- tidier flagging of _NEW_MULTISAMPLE
- fix weird indentation in get.c
V4: - move flush later in SampleMaski()
Signed-
Actual sample locations deferred to a driverfunc since only the driver
really knows where they will be.
V2: - pass the draw buffer to the driverfunc; don't fallback to pixel
center if driverfunc is missing.
- rename GetSampleLocation to GetSamplePosition
- invert y sample position fo
V2: For now, only expose a depth sample count of 1, since there are
unresolved interactions with W-tiling for stencil textures and possibly
also HiZ for depth textures.
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
Reviewed-by: Eric Anholt
---
src/mesa/drivers/dri/i965/brw_context.c | 12
- GL_MAX_COLOR_TEXTURE_SAMPLES
- GL_MAX_DEPTH_TEXTURE_SAMPLES
- GL_MAX_INTEGER_SAMPLES
V2: initialize limits to 1 in _mesa_init_constants as suggested by Brian
and Paul
Signed-off-by: Chris Forbes
Reviewed-by: Paul Berry
Reviewed-by: Eric Anholt
---
src/mesa/main/context.c | 5 +
1 - 100 of 105 matches
Mail list logo
