http://bugs.freedesktop.org/show_bug.cgi?id=26820
--- Comment #3 from Stefan Zerbst 2010-03-01 23:32:54 PST
---
Created an attachment (id=33681)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33681)
Sample program to reproduce the crash
This sample program (simple Windows OpenGL sampl
Another trivial patch: nouveau classic driver has everything needed for
GL_NV_blend_square, just expose extension. Tested with tests/blendsquare
В сообщении от Monday 01 March 2010 02:25:01 вы написали:
> randrianas...@gmail.com writes:
> > Hello all!
> >
> > After unsuccesfull battle with git-se
From fa7842908e2109b5c976e0d7082f67dfe2437dc2 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu
Date: Tue, 2 Mar 2010 03:29:51 +
Subject: [PATCH] nouveau: Trivially add GL_ARB_texture_mirrored_repeat. Texwrap demo not working fully yet
---
src/mesa/drivers/dri/nouveau/nouveau_context.c |
В сообщении от Monday 01 March 2010 02:25:01 Francisco Jerez написал(а):
> randrianas...@gmail.com writes:
> > Hello all!
> >
> > After unsuccesfull battle with git-send-email I just send these two
> > patches from Kmail. Botch as attachments and inlin, but inline version
> > probably will be dam
Hi Guys,
I am trying to implement the openGL Readpixels for depth buffer in plain
c++. I have tried to dig into openGL for this but I think this is protected
and I think its done in hardware. I tried to look in mesa but can't seem to
track it down. If anyone knows which file the mesa code is i
http://bugs.freedesktop.org/show_bug.cgi?id=26832
--- Comment #1 from Magnus Kessler 2010-03-01
22:50:14 PST ---
Created an attachment (id=33677)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33677)
proposed fix
On closer inspection it appears that the variable "data" in glx_puffer.c
http://bugs.freedesktop.org/show_bug.cgi?id=26832
Summary: [bisected glx]: assert triggered by kwin, when
glxCreateWindow is called with NULL attrib_list
Product: Mesa
Version: git
Platform: All
OS/Version: All
Stat
On Tue, 2010-03-02 at 04:02 +0100, Roland Scheidegger wrote:
> On 02.03.2010 00:18, Joakim Sindholt wrote:
> > On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> >> Hi,
> >>
> >> this branch turns vertex element into a cso, so instead of
> >> set_vertex_elements there's now the triad of
On 02.03.2010 00:18, Joakim Sindholt wrote:
> On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
>> Hi,
>>
>> this branch turns vertex element into a cso, so instead of
>> set_vertex_elements there's now the triad of
>> create/bind/delete_vertex_elements_state. I have converted all the
>>
Ahhh, I am a bad liar. The attached patch fixes the regressions.
-Marek
On Tue, Mar 2, 2010 at 2:08 AM, Marek Olšák wrote:
> Hi Michal,
>
> This branch breaks 2 piglit tests with r300g:
>
> depthrange-clear
> texdepth
>
> However I haven't investigated these and won't get to them until the
> we
that was me, should compile now
On Tue, Mar 2, 2010 at 3:22 AM, Mike Stroyan wrote:
> The recent changes to _glapi_check_table included building the full
> version build every time. That broke builds for OpenGL ES1 and
> OpenGL ES2. They don't have all of the table members that OpenGL
> does.
>
The recent changes to _glapi_check_table included building the full
version build every time. That broke builds for OpenGL ES1 and
OpenGL ES2. They don't have all of the table members that OpenGL
does.
This first broke in commit 42f3241e04b6cd74829dfb64b4a154ac8a4e6a48
in glapi/glapi.c.
But the p
Hi Michal,
This branch breaks 2 piglit tests with r300g:
depthrange-clear
texdepth
However I haven't investigated these and won't get to them until the
weekend. I personally don't mind fixing the regressions after the merge (but
I'm not the maintainer of r300g). Anyway I'm glad to see
bypass_vs_
On Tue, Mar 2, 2010 at 12:38 AM, Johannes Obermayr
wrote:
> Latest mesa does not compile.
>
> Thanks.
> Johannes
>
>
> gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
> -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There are a few places in Mesa where we check the GCC version and have
alternate code paths. It looks like almost all of the checks go away if
we require GCC version of at least 3.3.0. The last 3.2 (or earlier)
release was in April of 2003. It seems
On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> Hi,
>
> this branch turns vertex element into a cso, so instead of
> set_vertex_elements there's now the triad of
> create/bind/delete_vertex_elements_state. I have converted all the
> drivers except nouveau (I didn't do it because Chr
Bugzilla from johannesoberm...@gmx.de wrote:
>
> Latest mesa does not compile.
>
> Thanks.
> Johannes
>
>
> gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
> -I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-st
Latest mesa does not compile.
Thanks.
Johannes
gcc -c -I../../include -I../../src/mesa -I../../src/gallium/include
-I../../src/gallium/auxiliary -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM
Hi.
I've got motherboard with Intel i855GME card.
I've build eagle (from krh's repository, commit
5af77e7525f42d7c5fa4429a633cf844d6b935f2) using:
1. drm-2.4.18
2. Mesa-7.7
3. linux kernel 2.6.33-rc8
And I was able to run demos fine (but gears with flicker sometimes).
After that I've started po
http://bugs.freedesktop.org/show_bug.cgi?id=26820
Karl Schultz changed:
What|Removed |Added
CC||karl.w.schu...@gmail.com
--- Comment #
R300 could benefit. I will push a patch to make it more useful after the
merge.
Posting from a mobile, pardon my terseness. ~ C.
On Mar 1, 2010 11:32 AM, "Roland Scheidegger" wrote:
On 01.03.2010 19:02, Roland Scheidegger wrote:
> Hi,
>
> this branch turns vertex element into a cs...
Ok, I've c
On 01.03.2010 19:02, Roland Scheidegger wrote:
> Hi,
>
> this branch turns vertex element into a cso, so instead of
> set_vertex_elements there's now the triad of
> create/bind/delete_vertex_elements_state. I have converted all the
> drivers except nouveau (I didn't do it because Christoph Bumille
I see that PK2US and friends are being removed.
These would be necessary to implement NV_fragment_program_option,
NV_fragment_program2 and NV_gpu_program4.
Currently the no drivers (including Nouveau) support them, but since
we already have some support in Mesa (even parsers for the nVidia
syntax)
Hi,
this branch turns vertex element into a cso, so instead of
set_vertex_elements there's now the triad of
create/bind/delete_vertex_elements_state. I have converted all the
drivers except nouveau (I didn't do it because Christoph Bumiller
already did nv50, but I can give the rest of them a shot)
On Mon, 2010-03-01 at 09:03 -0800, Michel Dänzer wrote:
> On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c
http://bugs.freedesktop.org/show_bug.cgi?id=26820
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #1 fro
On Fri, 2010-02-26 at 08:47 -0800, Jose Fonseca wrote:
> Module: Mesa
> Branch: master
> Commit: 9beb302212a2afac408016cbd7b93c8b859e4910
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9beb302212a2afac408016cbd7b93c8b859e4910
>
> Author: José Fonseca
> Date: Fri Feb 26 16:45:22
On 1 mar 2010, at 13.45, Jakob Bornecrantz wrote:
> On 1 mar 2010, at 13.05, Keith Whitwell wrote:
>> On Thu, 2010-02-25 at 20:46 -0800, Jakob Bornecrantz wrote:
>>> Howdy
>>>
>>> I'm hoping to merge the gallium-winsys-handle branch to master this
>>> weekend or early next week. The branch adds two
Hi,
This branch removes bypass_vs_clip_and_viewport flag from pipe
rasterizer state. The benefits of having this bit around were dubious
for everybody and burdensome for driver writers.
All the utility code that relied on this flag have been rewritten to
pass vertex positions in clip space an
Wow, this really got a lot of discussion.
I don't really care *where* the sanity code is, but it just seems
horribly wrong that it's got to be duplicated between per-hook
per-driver in a library that purports simplified drivers with reduced
LOCs. I suppose it's unavoidable to a degree as long as d
On Mon, 2010-03-01 at 07:32 -0800, Jakob Bornecrantz wrote:
> On 1 mar 2010, at 15.23, Jose Fonseca wrote:
> > Module: Mesa
> > Branch: gallium-format-cleanup
> > Commit: 4c3bfc9778d9a0a75bf93b15303a4839f971f695
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=4c3bfc9778d9a0a75bf93
On Mon, 2010-03-01 at 07:33 -0800, Olivier Galibert wrote:
> On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote:
> > Do you have solution/proposal/idea on how to handle the situation
> > i am describing ?
>
> I've been looking at gallium from far away, but it seems to me you
> have two
On Mon, 2010-03-01 at 06:24 -0800, Olivier Galibert wrote:
> On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote:
> > validate function i have in mind as virtualy a zero cost (it will
> > boil down to a bunch of add followed by a test) and what validate
> > would do would be done by draw
On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote:
> Do you have solution/proposal/idea on how to handle the situation
> i am describing ?
I've been looking at gallium from far away, but it seems to me you
have two independant issues:
- informing the caller of errors in atomic draw() c
On Mon, Mar 01, 2010 at 04:21:45PM +0100, Marek Olšák wrote:
> On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse wrote:
>
> > On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote:
> > > On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
> > > > On Mon, 2010-03-01 at 03:55 -0800, Jerome
On 1 mar 2010, at 15.23, Jose Fonseca wrote:
> Module: Mesa
> Branch: gallium-format-cleanup
> Commit: 4c3bfc9778d9a0a75bf93b15303a4839f971f695
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4c3bfc9778d9a0a75bf93b15303a4839f971f695
>
> Author: José Fonseca
> Date: Mon Mar 1 15:17
On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse wrote:
> On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote:
> > On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
> > > On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
> > > > On Mon, Mar 01, 2010 at 11:46:08AM +, Keith
On Mon, Mar 01, 2010 at 03:24:51PM +0100, Olivier Galibert wrote:
> On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote:
> > validate function i have in mind as virtualy a zero cost (it will
> > boil down to a bunch of add followed by a test) and what validate
> > would do would be done b
http://bugs.freedesktop.org/show_bug.cgi?id=26820
Summary: Sharing contexts crashes on Windows
Product: Mesa
Version: 7.6
Platform: All
OS/Version: Windows (All)
Status: NEW
Severity: critical
Priority: high
On Mon, Mar 01, 2010 at 02:57:08PM +0100, Jerome Glisse wrote:
> validate function i have in mind as virtualy a zero cost (it will
> boil down to a bunch of add followed by a test) and what validate
> would do would be done by draw operation anyway.
Not "would", "will". You have no way to be sure
On 1 mar 2010, at 13.05, Keith Whitwell wrote:
> On Thu, 2010-02-25 at 20:46 -0800, Jakob Bornecrantz wrote:
>> Howdy
>>
>> I'm hoping to merge the gallium-winsys-handle branch to master this
>> weekend or early next week. The branch adds two new pipe screen
>> functions to be used by the co state
On Mon, Mar 01, 2010 at 12:24:19PM +, Keith Whitwell wrote:
> On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
> > On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
> > > On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
> > > > On Mon, 2010-03-01 at 03:21 -0800, Jos
On Mon, Mar 01, 2010 at 01:40:37PM +0100, Olivier Galibert wrote:
> On Mon, Mar 01, 2010 at 12:55:09PM +0100, Jerome Glisse wrote:
> > So you don't like the pipe_context::validate() of Jose ? My
> > taste goes to the pipe_context::validate() and having state
> > tracker setting the proper flag acco
On Wed, 2010-02-24 at 16:48 -0800, Mike Stroyan wrote:
> The ifdef changes to allow building with older libdrm and glproto
> header files are working.
> But the configure.ac requirements are still aggressive, requiring
> LIBDRM_REQUIRED=2.4.15
> and
> GLPROTO_REQUIRED=1.4.11
> Could those back down
On Thu, 2010-02-25 at 20:46 -0800, Jakob Bornecrantz wrote:
> Howdy
>
> I'm hoping to merge the gallium-winsys-handle branch to master this
> weekend or early next week. The branch adds two new pipe screen
> functions to be used by the co state tracker (state tracker manger in
> new st_api.h sp
Falling back to CPU rendering, while respecting the OpenGL spec, is
likely going to be unusably slow in most cases and thus not really
better for real usage than just not rendering.
I think the only way to have an usable fallback mechanism is to do
fallbacks with the GPU, by automatically introduc
On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
> On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
> > On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
> > > On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> > > > On Sun, 2010-02-28 at 11:25 -0800, Jerome Gliss
On Mon, Mar 01, 2010 at 12:55:09PM +0100, Jerome Glisse wrote:
> So you don't like the pipe_context::validate() of Jose ? My
> taste goes to the pipe_context::validate() and having state
> tracker setting the proper flag according to the API they
> support (GL_OUT_OF_MEMORY for GL), this means just
On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote:
> On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
> > On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> > > On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> > > > Hi,
> > > >
> > > > I am a bit puzzled, how a p
On Mon, Mar 01, 2010 at 11:46:08AM +, Keith Whitwell wrote:
> On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> > On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> > > Hi,
> > >
> > > I am a bit puzzled, how a pipe driver should handle
> > > draw callback failure ? On radeon (pr
On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote:
> On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> > Hi,
> >
> > I am a bit puzzled, how a pipe driver should handle
> > draw callback failure ? On radeon (pretty sure nouveau
> > or intel hit the same issue) we can only know when one
On Sun, 2010-02-28 at 21:35 -0800, Corbin Simpson wrote:
> On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie wrote:
> > On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt wrote:
> >> On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
> >>> Hi,
> >>>
> >>> I am a bit puzzled, how a pipe driver shoul
On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote:
> Hi,
>
> I am a bit puzzled, how a pipe driver should handle
> draw callback failure ? On radeon (pretty sure nouveau
> or intel hit the same issue) we can only know when one
> of the draw_* context callback is call if we can do
> the render
Here's an interesting regression caused by Mesa commit
c76d4db25260dd68684bf784efacd7323c7cab8b
(http://cgit.freedesktop.org/mesa/mesa/commit/?id=c76d4db25260dd68684bf784efacd7323c7cab8b).
It shows itself only when Mesa is configured with --enable-debug. In this case
the i965_dri.so driver can
54 matches
Mail list logo
