This code was introduced in 5b542681dc05b8b9eba677ee74323ac0ff85a5f0 to fix
https://bugs.freedesktop.org/show_bug.cgi?id=53617 however llvmpipe (and
others) no longer return early if the count doesnt include old views as of
around 177c9be61535a66607e0de9b0ecf00c8d5d451ac.
Also I believe 2355a64
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #2 from Florian Link ---
Created attachment 99394
--> https://bugs.freedesktop.org/attachment.cgi?id=99394&action=edit
some screenshots showing the problem
I rendered the same cube two times, first culling the front faces, then cul
https://bugs.freedesktop.org/show_bug.cgi?id=78773
--- Comment #5 from Jan ---
Created attachment 99395
--> https://bugs.freedesktop.org/attachment.cgi?id=99395&action=edit
log file
i attached the log file. game also started to lower to my resolution to 640x480
which it didnt do in my first tr
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #3 from Florian Link ---
So regarding your comment, rasterization of back/front faces with shared edges
seems to rasterize to different (at least on some pixels). So it is not about
the interpolated vertex attributes, but about the sc
Reviewed-by: Jeremy Huddleston Sequoia with one minor
change (see below):
On May 13, 2014, at 05:15, Jon TURNEY wrote:
...
> diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
> index eee7c2c..c18d1c5 100644
> --- a/src/glx/Makefile.am
> +++ b/src/glx/Makefile.am
> @@ -24,7 +24,7 @@ SHARE
Reviewed-by: Jeremy Huddleston Sequoia
On May 13, 2014, at 05:15, Jon TURNEY wrote:
> - Don't require xcb-dri[23] etc. if we aren't building for a target with DRM,
> as
> we won't be using dri[23]
>
> - Enable a more fine-grained control of what DRI code is built, so that a
> libGL
> using d
On 20/05/14 04:49, Jonathan Gray wrote:
> On Mon, May 19, 2014 at 11:57:58PM +0100, Emil Velikov wrote:
>> On 18/05/14 12:22, Jonathan Gray wrote:
>> [snip]
>>>
>>> Currently I run my autotools builds like this:
>>>
>>> export LDFLAGS=-L/usr/local/lib
>>> export CPPFLAGS="-I/usr/local/include -I/us
Acked-by: Jakob Bornecrantz
On Sun, May 18, 2014 at 9:07 AM, Emil Velikov wrote:
> Unmaintained and broken.
>
> Cc: Jakob Bornecrantz
> Signed-off-by: Emil Velikov
> ---
> scons/gallium.py | 1 -
> src/gallium/SConscript| 9 -
> src/galli
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #4 from Roland Scheidegger ---
I agree this looks like a rasterization problem. I'll look into it when I find
some time. Right now I have no idea why that happens - there's the code which
would rotate the vertices but this all happens
On Tue, May 20, 2014 at 7:38 AM, Rogovin, Kevin wrote:
>
>>> For OpenGL ES, I propose a simpler solution:
>>> - don't touch ARB_texture_float at all
>>> - add OES_texture_float to gl_extensions
>>> - add OES_texture_float_linear to gl_extensions
>>> - define OES_texture_half_float as o(OES_texture
On Sun, May 18, 2014 at 9:07 AM, Emil Velikov wrote:
> Will be used to control the linking mode of pipe-drivers
> in gallium targets.
>
> XXX: Do we want to expose this via configure option ?
> I'm personally inclined to use pipe-drivers despite the
> unstable interface between them and the rest o
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #5 from Florian Link ---
Created attachment 99406
--> https://bugs.freedesktop.org/attachment.cgi?id=99406&action=edit
apitrace of example
The rendering is in frame 6, 7 and 9. I don't know how to strip the MeVisLab
network renderi
On 20/05/2014 09:57, Jeremy Huddleston Sequoia wrote:
Reviewed-by: Jeremy Huddleston Sequoia with one minor change (see below):
Thanks very much for taking the time to review these.
On May 13, 2014, at 05:15, Jon TURNEY wrote:
+SUBDIRS+=. tests
+
include $(top_srcdir)/install-lib-links.mk
Hey Ian,
I wonder to what extent you might tolerate a late freedreno pull req?
I've backported nearly all of the recent freedreno commits on master
to a 10.2 based branch:
https://github.com/freedreno/mesa/commits/freedreno-10.2
I guess it will be a while before 10.3 makes it in to distros, so
https://bugs.freedesktop.org/show_bug.cgi?id=78773
--- Comment #6 from Brian Paul ---
Wasn't Doom 3 one of those older games that had a fixed-size buffer for storing
the GL_EXTENSIONS string? If the extension string was too long the buffer
would overflow and the game would crash/misbehave.
Jan,
On 20/05/14 13:08, Marek Olšák wrote:
> On Sun, May 18, 2014 at 9:07 AM, Emil Velikov
> wrote:
>> Will be used to control the linking mode of pipe-drivers
>> in gallium targets.
>>
>> XXX: Do we want to expose this via configure option ?
>> I'm personally inclined to use pipe-drivers despite the
https://bugs.freedesktop.org/show_bug.cgi?id=78773
--- Comment #7 from Tapani Pälli ---
(In reply to comment #6)
> Wasn't Doom 3 one of those older games that had a fixed-size buffer for
> storing the GL_EXTENSIONS string? If the extension string was too long the
> buffer would overflow and the
Well, I have never studied the build system, so I don't know exactly
what this series does and how it affects the size of the drivers.
Could you please summarize what binaries are created, how big they
are, and compare the shared vs static approach vs the current way? And
what is the role of the p
On 05/20/2014 04:56 AM, Ilia Mirkin wrote:
In commit 4be146b1, I neglected to add the new property to the strings
array. This leads to the string '(null)' to be printed instead when
converting a GS shader to text.
Signed-off-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/auxiliary/tgsi/tgsi_stri
On May 20, 2014, at 05:57, Jon TURNEY wrote:
> On 20/05/2014 09:57, Jeremy Huddleston Sequoia wrote:
>> Reviewed-by: Jeremy Huddleston Sequoia with one minor change (see below):
>
> Thanks very much for taking the time to review these.
No, thank you for taking the time to do them.
>> On May
On Tue, May 20, 2014 at 11:28 AM, Roland Scheidegger wrote:
> On 05/20/2014 04:56 AM, Ilia Mirkin wrote:
>>
>> In commit 4be146b1, I neglected to add the new property to the strings
>> array. This leads to the string '(null)' to be printed instead when
>> converting a GS shader to text.
>>
>> Sign
It seems unusual for a new extension to be defined in its own header
file rather than the eglext.h file.
Is there a particular reason for that? Are there other vendors putting
their extensions in new header files like this?
-Brian
On 05/16/2014 04:05 PM, Chad Versace wrote:
Ian and Brian,
Matt Turner writes:
> On Mon, May 19, 2014 at 10:56 AM, Aras Pranckevicius wrote:
>> Hi,
>>
>> When Mesa's GLSL compiler is faced with a code like this:
>>
>> // vec4 packednormal exists
>> vec3 normal;
>> normal.xy = packednormal.wy * 2.0 - 1.0;
>> normal.z = sqrt(1.0 - dot(norm
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #6 from Roland Scheidegger ---
Actually I think I know what's happening here. Our rasterizer can only handle
counterclockwise triangles (so the edge function sign indicates if a fragment
is inside or outside a plane and ultimately the
On Tue, May 20, 2014 at 12:07:15AM +0100, Emil Velikov wrote:
> As you can notice I'm not a huge fan of adding yet another way of
> retrieving the device/driver name although I would not object if
> you're willing to split this patch a bit, have the option off by
> default and fix bugs if/when they
On Tue, May 20, 2014 at 9:14 AM, Brian Paul wrote:
> It seems unusual for a new extension to be defined in its own header file
> rather than the eglext.h file.
>
> Is there a particular reason for that? Are there other vendors putting
> their extensions in new header files like this?
>
>
The rea
_mesa_meta_setup_blit_shader() currently generates a fragment shader
which, irrespective of the number of draw buffers, writes the color
to only one 'out' variable. Current shader rely on an undefined
behavior and possibly works by chance.
>From OpenGL 4.0 spec, page 256:
"If a fragment shader
Cc:
Signed-off-by: Anuj Phogat
Reviewed-by: Matt Turner
---
src/mesa/drivers/common/meta.c | 101 -
1 file changed, 48 insertions(+), 53 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3ef3f79..fab9106 1006
Note that this covers the Begin/End rendering path, but not user vertex
arrays (so we can't drop copy_array_to_vbo_array() code). Improves
performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934%
(n=20). No difference on openarena (n=10), which was why this was reverted
back in cbde27658
On Tue, May 20, 2014 at 10:31:05AM -0700, Anuj Phogat wrote:
> _mesa_meta_setup_blit_shader() currently generates a fragment shader
> which, irrespective of the number of draw buffers, writes the color
> to only one 'out' variable. Current shader rely on an undefined
> behavior and possibly works b
On 20/05/14 18:04, Gary Wong wrote:
> On Tue, May 20, 2014 at 12:07:15AM +0100, Emil Velikov wrote:
>> As you can notice I'm not a huge fan of adding yet another way of
>> retrieving the device/driver name although I would not object if
>> you're willing to split this patch a bit, have the option o
On Tue, May 20, 2014 at 10:18:50AM -0700, Stéphane Marchesin wrote:
>
>
>
> On Tue, May 20, 2014 at 9:14 AM, Brian Paul wrote:
>
> It seems unusual for a new extension to be defined in its own header file
> rather than the eglext.h file.
>
> Is there a particular reason for that?
On 05/20/2014 12:21 PM, Chad Versace wrote:
On Tue, May 20, 2014 at 10:18:50AM -0700, Stéphane Marchesin wrote:
On Tue, May 20, 2014 at 9:14 AM, Brian Paul wrote:
It seems unusual for a new extension to be defined in its own header file
rather than the eglext.h file.
Is ther
On Fri, May 9, 2014 at 6:21 AM, Juha-Pekka Heikkila
wrote:
> On ILK implicit accumulator write from MUL opcode seem to
> behave sometime unexpected. This patch change implicit
> accumulator write to explicit on emitting LRP for gen<6.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=7770
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #7 from Roland Scheidegger ---
Hmm actually that theory wasn't right. Must be something else.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing
Hello,
I attempted doing this a while back, before I really understood what
was going on. I got some advice that went totally over my head, and I
dropped the issue. I think I'm much better-prepared to tackle the
issue this time around.
To recap, nv30 (and nv40) hw can't handle certain color/depth
At this point, the extra copy of the data and memcmp are as expensive as
just re-uploading.
Note: now that we'll always upload, and brw_constant_buffer watches
BRW_NEW_BATCH anyway, we don't need to explicitly unref the old curbe_bo
at batch reset time.
No significant performance difference on gl
No performance difference on glamor with copywinwin10 (n=40) on my gm45.
---
src/mesa/drivers/dri/i965/brw_context.h | 6 --
src/mesa/drivers/dri/i965/brw_curbe.c | 31 +++
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 1 -
3 files changed, 7 insertion
On 20/05/14 16:21, Marek Olšák wrote:
> Well, I have never studied the build system, so I don't know exactly
> what this series does and how it affects the size of the drivers.
>
> Could you please summarize what binaries are created, how big they
> are, and compare the shared vs static approach v
On Tue, May 20, 2014 at 10:31:04AM -0700, Anuj Phogat wrote:
> Cc:
> Signed-off-by: Anuj Phogat
> Reviewed-by: Matt Turner
> ---
> src/mesa/drivers/common/meta.c | 101
> -
> 1 file changed, 48 insertions(+), 53 deletions(-)
>
> diff --git a/src/mesa/dr
On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin wrote:
> Hello,
>
> I attempted doing this a while back, before I really understood what
> was going on. I got some advice that went totally over my head, and I
> dropped the issue. I think I'm much better-prepared to tackle the
> issue this time around
On Tue, May 20, 2014 at 4:51 PM, Marek Olšák wrote:
> On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin wrote:
>> Hello,
>>
>> I attempted doing this a while back, before I really understood what
>> was going on. I got some advice that went totally over my head, and I
>> dropped the issue. I think I'm
On Tue, May 20, 2014 at 1:47 PM, Pohjolainen, Topi
wrote:
> On Tue, May 20, 2014 at 10:31:04AM -0700, Anuj Phogat wrote:
>> Cc:
>> Signed-off-by: Anuj Phogat
>> Reviewed-by: Matt Turner
>> ---
>> src/mesa/drivers/common/meta.c | 101
>> -
>> 1 file chan
On Tue, May 20, 2014 at 12:10 PM, Matt Turner wrote:
> On Fri, May 9, 2014 at 6:21 AM, Juha-Pekka Heikkila
> wrote:
>> On ILK implicit accumulator write from MUL opcode seem to
>> behave sometime unexpected. This patch change implicit
>> accumulator write to explicit on emitting LRP for gen<6.
>>
On 05/20/2014 10:49 AM, Pohjolainen, Topi wrote:
> On Tue, May 20, 2014 at 10:31:05AM -0700, Anuj Phogat wrote:
>> _mesa_meta_setup_blit_shader() currently generates a fragment shader
>> which, irrespective of the number of draw buffers, writes the color
>> to only one 'out' variable. Current shade
On 05/20/2014 11:00 AM, Eric Anholt wrote:
> Note that this covers the Begin/End rendering path, but not user vertex
> arrays (so we can't drop copy_array_to_vbo_array() code). Improves
> performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934%
> (n=20). No difference on openarena (n=10)
brw_color_buffer_write_enabled depends on brw->fragment_program, which
means we have to listen to BRW_NEW_FRAGMENT_PROGRAM.
On most generations, this was only called from a function that already
subscribed. However, on Broadwell, we failed to listen to the necessary
event in the atom that emits 3
I forgot to disable writemasking on the OR and MOV which set the render
target index and "source 0 alpha present to render target" bit.
Using get_element_ud is equivalent and avoids a line-wrap.
Signed-off-by: Kenneth Graunke
Cc: "10.2"
---
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 13
On Tue, May 20, 2014 at 2:36 PM, Kenneth Graunke wrote:
> On 05/20/2014 10:49 AM, Pohjolainen, Topi wrote:
>> On Tue, May 20, 2014 at 10:31:05AM -0700, Anuj Phogat wrote:
>>> _mesa_meta_setup_blit_shader() currently generates a fragment shader
>>> which, irrespective of the number of draw buffers,
On 05/19/2014 10:20 PM, Tapani wrote:
> On 05/19/2014 08:26 PM, Ian Romanick wrote:
>> On 04/09/2014 02:56 AM, Tapani Pälli wrote:
>>> Patch adds new implementation dependent value required by the
>>> GL_ARB_explicit_uniform_location extension. Default value for user
>>> assignable locations is cal
On 05/19/2014 10:13 PM, Tapani wrote:
> On 05/19/2014 08:21 PM, Ian Romanick wrote:
>> Either this patch should:
>>
>> - Delete the extension enable flag
>> - Change the table in extensions.c to use dummy_true
>>
>> or
>>
>> The next patch needs to not say "all drivers that support GLSL".
>>
>>
On Tue, May 20, 2014 at 11:00 AM, Eric Anholt wrote:
> Note that this covers the Begin/End rendering path, but not user vertex
> arrays (so we can't drop copy_array_to_vbo_array() code). Improves
> performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934%
> (n=20). No difference on opena
On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin wrote:
> On Tue, May 20, 2014 at 4:51 PM, Marek Olšák wrote:
>> On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin wrote:
>>> Hello,
>>>
>>> I attempted doing this a while back, before I really understood what
>>> was going on. I got some advice that went
Both are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 05/19/2014 10:08 PM, Tapani wrote:
> On 05/19/2014 08:18 PM, Ian Romanick wrote:
>> On 04/09/2014 02:56 AM, Tapani Pälli wrote:
>>> Patch adds a preprocessor define for the extension and stores explicit
>>> location data for uniforms during AST->HIR conversion. It also sets
>>> layout token to b
Mesa 10.1.4 has been released. Mesa 10.1.4 is a bug fix release which
fixes bugs fixed since the 10.1.3 release, (see below for a list of
changes).
The tag in the git repository for Mesa 10.1.4 is 'mesa-10.1.4'.
Mesa 10.1.4 is available for download at
ftp://freedesktop.org/pub/mesa/10.1.4/
md5s
Thanks, that makes sense. I think the static approach is better, but I
don't have a strong opinion about that.
Did you also consider merging the API libraries?
For DRI, we need to export __driDriverExtensions.
For VDPAU, we need to export vdp_imp_device_create_x11.
Etc.
However, having a single
I went through the gallium-nine tree and picked out nouveau patches that are
general bug-fixes. The first bunch I'd like to also get into 10.2. I've
reviewed all of them and they make sense to me, but sending them out for
public review as well in case there are any objections.
Unless I hear object
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/n
From: Christoph Bumiller
[imirkin: add logic to also clear the "regular" scissors]
Reviewed-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/
From: Christoph Bumiller
Note that predicated instructions with defs are still not supported
because transformation to SSA doesn't handle them yet.
Reviewed-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 5 -
1 file changed, 4 insertions(+),
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 7 ++-
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 9 +
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_cont
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/nouveau/nv50/nv50_state_validate.c | 4
src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_formats.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_formats.c
b/src/gallium/drivers/nouveau/nv50/nv50_formats.c
index 3af34c1..ff3
From: Christoph Bumiller
[imirkin: moved default case out of switch]
Reviewed-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 10 --
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/g
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 1d59fc4..8724cc5 100
From: Christoph Bumiller
Reviewed-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
index c58d6da..83d406d 100644
--- a/src/gallium/driver
From: Joakim Sindholt
But don't count their size towards the allocated memory, since that
belongs to whoever created it.
Reviewed-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_mipt
Hi,
Could somebody from VMWare please review this patch? It's for st/nine
(open d3d9 state tracker).
Thanks,
Marek
On Sat, May 17, 2014 at 1:20 AM, Automated rebase
wrote:
> From: Christoph Bumiller
>
> ---
> src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
> src/gallium/auxiliary/tgsi/t
On 21/05/14 00:32, Marek Olšák wrote:
> Thanks, that makes sense. I think the static approach is better, but I
> don't have a strong opinion about that.
>
> Did you also consider merging the API libraries?
>
> For DRI, we need to export __driDriverExtensions.
> For VDPAU, we need to export vdp_im
On 19/05/14 16:02, Kai Wasserbäch wrote:
> Without this, I get linking failures (static linking).
>
> The static linking is sort of required for me, because otherwise Steam and
> applications using the Steam runtime regularily fail because my LLVM was
> compiled and linked against a newer libgcc_s
On 14/05/14 20:16, Thomas Hellstrom wrote:
> Hi, I'm on vacation, so I have no way of testing this until next week.
>
Hi Thomas,
With the next week upon us can you spare a few minutes to check that I've not
butchered the API ?
Perhaps you'll have the chance to poke Brian to see patches 3/4 and 4
Just realised that I had forgotten about mangled gl. So this patch will need
an extra line in the global symbols list.
mgl*;
I would still appreciate if someone familiar with OSMesa's api can take a look
Cheers,
Emil
On 09/05/14 18:13, Emil Velikov wrote:
> ping,
>
> Brian, you seem to be t
Similar to 3/4 I will the mangled gl symbols to the global list.
mgl*;
Other than that, an acked-by would be appreciated :)
-Emil
On 09/05/14 18:15, Emil Velikov wrote:
> Ping
>
> Btw the TODO list here was for my personal reference, I'll change/nuke it
> before pushing.
>
> Cheers,
> Emil
On Tue, May 20, 2014 at 6:20 PM, Marek Olšák wrote:
> On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin wrote:
>> On Tue, May 20, 2014 at 4:51 PM, Marek Olšák wrote:
>>> On Tue, May 20, 2014 at 9:58 PM, Ilia Mirkin wrote:
Hello,
I attempted doing this a while back, before I really un
---
.../targets/haiku-softpipe/GalliumContext.cpp |1 +
.../targets/haiku-softpipe/GalliumFramebuffer.cpp |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumContext.cpp
b/src/gallium/targets/haiku-softpipe/GalliumContext.cp
ARB_buffer_storage doesn't have anything to do with framebuffers.
Marek
On Wed, May 21, 2014 at 2:27 AM, Ilia Mirkin wrote:
> On Tue, May 20, 2014 at 6:20 PM, Marek Olšák wrote:
>> On Tue, May 20, 2014 at 11:04 PM, Ilia Mirkin wrote:
>>> On Tue, May 20, 2014 at 4:51 PM, Marek Olšák wrote:
>>>
Can you not render to a texture buffer? That might not be supported by
nv30 actually.
On Tue, May 20, 2014 at 8:49 PM, Marek Olšák wrote:
> ARB_buffer_storage doesn't have anything to do with framebuffers.
>
> Marek
>
> On Wed, May 21, 2014 at 2:27 AM, Ilia Mirkin wrote:
>> On Tue, May 20, 2014
It's not relevant to anything we have. The last I looked st/nine wasn't even an
umd. Everything that's needed for a d3d9 (and d3d10) umd's has already been
added to gallium, we don't have any patches against core gallium that we've
been keeping from the community. All we could do is review the p
loader_get_pci_id_for_fd() and loader_get_device_name_for_fd() now attempt
all available strategies to identify the hardware, instead of conditionally
compiling in a single test. The existing libudev and DRM approaches have
been retained, and another simple alternative of looking up the answer in
loader_get_pci_id_for_fd() and loader_get_device_name_for_fd() now attempt
all available strategies to identify the hardware, instead of conditionally
compiling in a single test. The existing libudev and DRM approaches have
been retained, attempting first libudev (if available) and then DRM (if
ne
Introduce a simple PCI identification method of looking up the answer
the /sys filesystem (available on Linux). Attempted after libudev, but
before DRM.
Disabled by default (available only when the --enable-sysfs configure
option is specified).
Signed-off-by: Gary Wong
---
configure.ac
https://bugs.freedesktop.org/show_bug.cgi?id=78771
--- Comment #11 from qwang13 ---
Thanks U. Artie Eoff's checking.
Currently we found the root cause is miss installing latest libgbm package.
--
You are receiving this mail because:
You are the QA Contact for the bug.
_
Hi,
On Monday, May 19, 2014 15:59:30 Michel Dänzer wrote:
> On 19.05.2014 15:03, Mathias Fröhlich wrote:
> >
> > I tried to get my local llvm install again to a point where I can see
> > backtrace information, but still failed to get valgrind/massif to print
> > these nice backtraces. All of the
86 matches
Mail list logo
