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 this.
- Proxy texture targets were denied in
Adds new enums, dispatch machinery, and stubs for the 4 new entrypoints.
V2: - Drop placeholder
- Align enum values
- Remove explicit exec=mesa; it *is* the dispatch flavor we want,
but it's also the default. I misunderstood how this worked before;
after actually reading the ge
Adds the new texture targets, and per-image state for GL_TEXTURE_SAMPLES
and GL_TEXTURE_FIXED_SAMPLE_LOCATIONS.
V2: - Allow multisample texture targets in glInvalidateTexSubImage too.
This was already partly there, but I missed it the first time around
since the interaction is defined
Signed-off-by: Chris Forbes
Reviewed-by: Eric Anholt
Reviewed-by: Paul Berry
---
src/mesa/main/tests/enum_strings.cpp | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/mesa/main/tests/enum_strings.cpp
b/src/mesa/main/tests/enum_strings.cpp
index 5d70007..1dae60f 10
V2: - emit `sample` parameter properly for multisample texelFetch()
- fix spurious whitespace change
- introduce a new opcode ir_txf_ms rather than overloading the
existing ir_txf further. This makes doing the right thing in
the driver somewhat simpler.
V3: - fix weird whitespa
- 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 +
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
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: - 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-
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/
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
- 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
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
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-
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
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
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
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:
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
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
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
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
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
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
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
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
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
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(+
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/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
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/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
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
---
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
-
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
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'
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
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
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
[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
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
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
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 =
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 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
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 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 #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
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 #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:
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
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/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
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
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
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
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
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
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
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
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
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:
> 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
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 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/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:
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
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/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
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/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
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/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
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
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
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
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 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.
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 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
Andreas Boll changed:
What|Removed |Added
Version|9.0 |9.1
--
You are receiving this mail becau
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
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,
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
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/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
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
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
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
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
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
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
---
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 |
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
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=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
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
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
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
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
1 - 100 of 105 matches
Mail list logo
