On 06.09.2010 15:57, José Fonseca wrote:
I'd like to know if there's any objection to change the
resource_copy_region semantics to allow copies between different yet
compatible formats, where the definition of compatible formats is:
formats for which copying the bytes from the source
On 06.09.2010 17:16, Luca Barbieri wrote:
On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca jfons...@vmware.com wrote:
I'd like to know if there's any objection to change the
resource_copy_region semantics to allow copies between different yet
compatible formats, where the definition of compatible
On 06.09.2010 22:03, Luca Barbieri wrote:
This way you could copy z24s8 to r8g8b8a8, for instance.
I am not sure this makes a lot of sense. There's no guarantee the bit
layout of these is even remotely similar (and it likely won't be on any
decent hardware). I think the dx10 restriction
On 13.04.2010 02:52, Dave Airlie wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Dave Airlie wrote:
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs
On 13.04.2010 20:28, Alex Deucher wrote:
On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger srol...@vmware.com
wrote:
On 13.04.2010 02:52, Dave Airlie wrote:
On Tue, Apr 6, 2010 at 2:00 AM, Brian Paul bri
On 14.04.2010 00:38, Dave Airlie wrote:
On Wed, Apr 14, 2010 at 8:33 AM, Roland Scheidegger srol...@vmware.com
wrote:
On 13.04.2010 20:28, Alex Deucher wrote:
On Tue, Apr 13, 2010 at 2:21 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
On Tue, Apr 13, 2010 at 6:42 AM, Roland Scheidegger
On 10.04.2010 14:00, Keith Whitwell wrote:
Hmm, not sure whether to merge or squash-merge this branch. Any thoughts?
I'm no big fan of squash merge but the history of the normal merge won't
be nice neither. Tough call, though I'd prefer a normal merge.
Roland
On 10.04.2010 16:43, Chia-I Wu wrote:
On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
keith.whitw...@googlemail.com wrote:
Hmm, not sure whether to merge or squash-merge this branch. Any thoughts?
The conversion to pipe_resource seems to be done by components. Maybe a new
branch that
On 10.04.2010 17:10, Keith Whitwell wrote:
On Sat, Apr 10, 2010 at 4:05 PM, Keith Whitwell
keith.whitw...@googlemail.com wrote:
On Sat, Apr 10, 2010 at 3:49 PM, Roland Scheidegger srol...@vmware.com
wrote:
On 10.04.2010 16:43, Chia-I Wu wrote:
On Sat, Apr 10, 2010 at 8:00 PM, Keith Whitwell
On 09.04.2010 17:49, Keith Whitwell wrote:
On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
Module: Mesa
Branch: gallium-resources
Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
On 09.04.2010 17:29, STEVE555 wrote:
Hi all,
I've git branched and got the latest commits from the
gallium-resources branch and also the latest commits from git master.
I did a gmake -B realclean from a prevous compile on my copy of git
master,and did a git checkout
On 09.04.2010 18:22, José Fonseca wrote:
On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote:
On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote:
On 09.04.2010 17:49, Keith Whitwell wrote:
On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
Module: Mesa
Branch: gallium
I'm planning on merging the gallium-resources branch shortly (after
easter). Due to the amount of code changed, it wouldn't be unexpected if
some drivers break here and there. So it would be nice if the respective
driver authors could take a look at that branch now.
If you've missed the
On 02.04.2010 17:09, Luca Barbieri wrote:
Additionally, the S3TC library may now support only a subset of the
formats. This may be even more useful as further compressed formats
are added.
FWIW, I don't see any new s3tc formats. rgtc will not be handled by s3tc
library since it isn't patent
On 29.03.2010 04:50, Marek Olšák wrote:
We were talking a bit on IRC that the GLSL compiler implements the sqrt
function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as
is in the original code, the proposed patch uses just rsq+mul. Please
see the patch log for further
On 16.03.2010 18:52, Keith Whitwell wrote:
On Tue, 2010-03-16 at 08:32 -0700, Ian Romanick wrote:
I'm also a bit surprised that not detecting GL_EXT_compiled_vertex_array
has any impact on our Quake3 performance. After all, our CVA
implementation doesn't do anything! Looking at the list,
Hi,
there are currently a couple of extensions enabled in the mesa state
tracker which probably shouldn't be. These were moved there by commit
a0ae2ca033ec2024da1e01d1c11c0437837c031b (that is with dri they were
already always enabled before).
Someone knows off-hand which one we can enable or
On 11.03.2010 17:54, Brian Paul wrote:
Roland Scheidegger wrote:
Hi,
there are currently a couple of extensions enabled in the mesa state
tracker which probably shouldn't be. These were moved there by commit
a0ae2ca033ec2024da1e01d1c11c0437837c031b (that is with dri they were
already always
On 07.03.2010 01:21, José Fonseca wrote:
On Sat, 2010-03-06 at 05:44 -0800, Brian Paul wrote:
On Sat, Mar 6, 2010 at 5:44 AM, José Fonseca jfons...@vmware.com wrote:
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
On 07.03.2010 20:26, Marek Olšák wrote:
This branch is aimed to address the following issues:
* Extensions are advertised in both st/mesa and st/dri, doing the same
thing in two places.
* The inability to disable extensions in pipe_screen::get_param because
st/dri overrides the decisions of
On 08.03.2010 14:22, Joakim Sindholt wrote:
On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
On 07.03.2010 20:26, Marek Olšák wrote:
This branch is aimed to address the following issues:
* Extensions are advertised in both st/mesa and st/dri, doing the same
thing in two places
?
-Marek
On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com wrote:
On 08.03.2010 14:22, Joakim Sindholt wrote:
On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
On 07.03.2010 20:26, Marek Olšák wrote
to be independent of windowing systems. That said from what I
can see both driInitExtensions and driInitSignleExtension could be
folded into mesa core, I can't see anything dri special about them.
Cheers Jakob.
On 8 mar 2010, at 16.12, Roland Scheidegger wrote:
Otherwise, looks good to me, but I'd
On 03.03.2010 14:07, José Fonseca wrote:
On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote:
PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa.
PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be
unnecessary. So it doesn't make sense to rename.
How about D3DFMT_X8B8G8R8? That
On 03.03.2010 20:23, Luca Barbieri wrote:
And never will... It does not export PIPE_CAP_GLSL, and does not have
the shader opcodes to ever do so.
Any Gallium driver should be able to support the GLSL subset without
control flow.
And if we had a proper optimization infrastructure capable
On 02.03.2010 11:37, Keith Whitwell wrote:
On Mon, 2010-03-01 at 10:02 -0800, 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
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
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 Bumiller
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
drivers
On 25.02.2010 18:39, michal wrote:
Roland Scheidegger wrote on 2010-02-24 15:18:
On 24.02.2010 12:48, Christoph Bumiller wrote:
This wasn't a problem before because textures and samplers were
linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
this coordinate normalization
On 24.02.2010 12:48, Christoph Bumiller wrote:
This wasn't a problem before because textures and samplers were
linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
this coordinate normalization bit becomes a problem.
NV50 hardware has that bit in the RESOURCE binding, and not
Marek,
I don't particularly like that patch, because it doesn't really fix the
problem with the extension handling.
There are lots of extension listed there which should not be advertized
by default, so picking one out won't fix the others.
I think they are there because driInitExtensions
This isn't actually true any more. See issue (9) of
ARB_framebuffer_object which defines luminance, luminance_alpha and
intensity as renderable.
(I'm not quite sure how color assignment is done, readpixels and the
like would define L = R + G + B, but I think it will follow the table
from texture
On 12.02.2010 14:44, michal wrote:
Keith Whitwell wrote on 2010-02-12 14:28:
On Fri, 2010-02-12 at 05:09 -0800, michal wrote:
Keith Whitwell wrote on 2010-02-12 13:39:
On Fri, 2010-02-12 at 04:32 -0800, Micha?? Kr??l wrote:
Module: Mesa
Branch: master
Commit:
On 12.02.2010 18:42, Keith Whitwell wrote:
On Fri, 2010-02-12 at 09:28 -0800, José Fonseca wrote:
On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote:
On 12.02.2010 14:44, michal wrote:
Keith Whitwell wrote on 2010-02-12 14:28:
On Fri, 2010-02-12 at 05:09 -0800, michal wrote
On 12.02.2010 19:00, Keith Whitwell wrote:
On Fri, 2010-02-12 at 09:56 -0800, Roland Scheidegger wrote:
On 12.02.2010 18:42, Keith Whitwell wrote:
On Fri, 2010-02-12 at 09:28 -0800, José Fonseca wrote:
On Fri, 2010-02-12 at 06:43 -0800, Roland Scheidegger wrote:
On 12.02.2010 14:44, michal
Hi,
could one of the nouveau developers please take a look at the nv30
changes I did for the stencil ref changes in gallium-dynamicstencilref
branch?
I've just done that in a way I think it might make sense, but I've
absolutely no idea if it would work like that (and even if it would in
theory
On 11.02.2010 21:42, Christoph Bumiller wrote:
On 02/11/2010 09:02 PM, Roland Scheidegger wrote:
Hi,
could one of the nouveau developers please take a look at the nv30
changes I did for the stencil ref changes in gallium-dynamicstencilref
branch?
I've just done that in a way I think
On 06.02.2010 15:07, Marc Dietrich wrote:
also update the cell config a bit
---
configs/linux-cell |6 ++--
src/gallium/drivers/cell/common.h |3 +-
src/gallium/drivers/cell/spu/spu_per_fragment_op.c | 36
++--
3
On 08.02.2010 18:27, Brian Paul wrote:
On Mon, Feb 8, 2010 at 10:21 AM, Roland Scheidegger srol...@vmware.com
wrote:
This branch removes point_size_min and point_size_max because most
hardware doesn't have any register to clamp this at rasterization time
(from all gallium drivers, only r300
On 05.02.2010 22:48, Corbin Simpson wrote:
Two things...
Are accumbufs still slow in Gallium-land? Should we still mark them as slow?
How many multisamples should we actually pretend/advertise? Should we
have a cap to check the number of multisamples supported? Should we
just say that
On 03.02.2010 16:07, michal wrote:
Keith,
This feature branch adds cylindrical wrap texcoord mode to gallium
shader tokens and removes prefilter field from sampler state.
Implemented cylindrical wrapping for linear interpolator in softpipe.
Not sure whether it makes sense to do it for
On 03.02.2010 17:45, michal wrote:
Roland Scheidegger wrote on 2010-02-03 16:47:
On 03.02.2010 16:07, michal wrote:
Keith,
This feature branch adds cylindrical wrap texcoord mode to gallium
shader tokens and removes prefilter field from sampler state.
Implemented cylindrical wrapping
On 31.01.2010 18:41, Christoph Bumiller wrote:
On 31.01.2010 01:37, Roland Scheidegger wrote:
Marek Olšák wrote:
6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
the fragment constants reads, Since Gallium doesn't support
GL_ARB_shadow_ambient
On 01.02.2010 20:23, Brian Paul wrote:
Speaking of texture formats and texture sampling, one area of Gallium
that's under-specified is what (x,y,z,w) values are returned by TEX
instructions when sampling from each of the various texture formats.
A while back I started a table comparing
On 30.01.2010 13:06, Corbin Simpson wrote:
Handful of random things bugging me.
2) progs/tests/drawbuffers and progs/tests/drawbuffers2, and possibly
others, segfault with both softpipe and the HW driver at
sl_pp_version.c:45. I think there's some codegen going on there? At
any rate, if
Marek Olšák wrote:
6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
the fragment constants reads, Since Gallium doesn't support
GL_ARB_shadow_ambient, this is always (0,0,0,0), right?
I think the extension could be added to Gallium since the r300 compiler
Corbin Simpson wrote:
Another
comment reads, Gallium doesn't provide us with any information
regarding this mode, so we are screwed. I'm setting 0 = LUMINANCE,
above the texture compare modes. I don't really like that section of
code, but it probably can't get cleaner, right?
Yes, that's
On 26.01.2010 09:18, Marvin wrote:
Jose, Brian,
Marc,
Why is this necessary? It has been working fine so far. Which gcc version
are you using? What commas are you referring to?
the PIPE_ALIGN_TYPE macro is so far only used in the cell driver in
src/gallium/drivers/cell/spu/spu_main.c
Hi,
I'm planning on merging this branch to master soon.
This will make it possible to do per render target blend enables,
colormasks, and also per rendertarget blend funcs (with a different CAP
bit for the latter, and this one isn't actually used in mesa state
tracker yet).
None of the drivers
, and
the r300g patch looks perfect. I've pushed another patch on top for
the pipe caps, to avoid post-merge cleanups for myself.
On Tue, Jan 26, 2010 at 7:00 AM, Alex Deucher alexdeuc...@gmail.com wrote:
On Tue, Jan 26, 2010 at 9:44 AM, Roland Scheidegger srol...@vmware.com
wrote:
Hi,
I'm planning
On 21.01.2010 18:47, Luca Barbieri wrote:
On Thu, Jan 21, 2010 at 6:34 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
Maybe it's just me, since I actually wrote the docs, but does anybody
else read them?
From cso/rasterizer.html (viewable at e.g.
On 21.01.2010 20:20, michal wrote:
Hi,
This simple feature branch adds support for two-dimensional constant
buffers in TGSI.
An example shader would look like this:
FRAG
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
DCL CONST[1][1..2]
MAD OUT[0], IN[0], CONST[1][2], CONST[1][1]
On 18.01.2010 19:15, Luca Barbieri wrote:
Breakpoint 3, _mesa_ProgramStringARB (target=34820, format=34933,
len=70, string=0x85922ba) at shader/arbprogram.c:434
434 GET_CURRENT_CONTEXT(ctx);
$31 = 0x85922ba !!ARBfp1.0\n\nOPTION
ARB_precision_hint_fastest;\n\n\n\nEND\n
On 11.01.2010 22:03, Zack Rusin wrote:
On Monday 11 January 2010 15:17:00 Roland Scheidegger wrote:
- extra mirror wrap modes - i don't think mirror repeat was ever
supported and mirror clamp was removed in d3d10 but it seems that some
hardware kept support for those
Mirror repeat is a core
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change, so things should continue to run :-).
Roland
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of
On 11.01.2010 16:42, Keith Whitwell wrote:
On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change, so things should continue to run :-).
Roland,
Before you do this, can you make sure
On 11.01.2010 16:53, Keith Whitwell wrote:
On Mon, 2010-01-11 at 07:50 -0800, Roland Scheidegger wrote:
On 11.01.2010 16:42, Keith Whitwell wrote:
On Mon, 2010-01-11 at 07:33 -0800, Roland Scheidegger wrote:
Hi,
I'll plan to merge gallium-noconstbuf today. It's a pretty simple API
change
On 11.01.2010 18:49, Zack Rusin wrote:
Hey,
knowing that we're starting to have serious issues with figuring out what
features the given device supports and what api's/extensions can be
reasonably
implemented on top of it I've spent the weekend trying to define feature
levels. Feature
On 04.01.2010 15:48, Brian Paul wrote:
Keith Whitwell wrote:
On Thu, 2009-12-31 at 15:57 -0800, Brian Paul wrote:
The BY_REGION modes indicate that it's OK for the GPU to discard the
fragments in the region(s) which failed the occlusion test (perhaps
skipping other per-fragment ops that would
On 01.01.2010 23:32, Luca Barbieri wrote:
Currently Gallium defines a specific filtering mode for anisotropic
filtering.
This however prevents proper implementation of
GL_EXT_texture_filter_anisotropic.
The spec (written by nVidia) contains the following text: A
texture's maximum degree
On 21.12.2009 15:13, Henri Verbeet wrote:
2009/12/21 Corbin Simpson mostawesomed...@gmail.com:
So, yet another thing that r300 sucks balls at: NPOT textures. We've
been talking it over on IRC, and here's the options.
1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept
non-NPOT
The draw module approach can only work if the texcoords are used
directly for texture lookups, not for calculated coords (it should be
possible to detect these cases though).
Roland
On 21.12.2009 19:32, Keith Whitwell wrote:
Faking those wrap modes is something that could be done either in the
Hello,
I plan to merge gallium-edgeflags branch soon.
I should have fixed up drivers syntactically, but note some will break
if applications use edgeflags. In particular the drivers which so far
have chosen to ignore edgeflags completely and don't have implemented a
fall back to use the draw
On 15.12.2009 14:14, michal wrote:
Guys,
Does the attached patch make sense to you?
I replaced the incomplete switch-cases with calls to u_format_access
functions that are complete but are going to be a bit more expensive to
call. Since they are used not very often in mesa state
On 15.12.2009 18:02, michal wrote:
Roland Scheidegger pisze:
On 15.12.2009 14:14, michal wrote:
Guys,
Does the attached patch make sense to you?
I replaced the incomplete switch-cases with calls to u_format_access
functions that are complete but are going to be a bit more expensive
On 14.12.2009 10:29, michael wang wrote:
Dear Mesa developers,
I am learning OpenGL on my notebook (with an old ATI Radeon X600 video
card), but I cannot get GL_LINE_STIPPLE work. It draws solid line only.
glxinfo shows I'm using the R300 driver, and some study of the source
code I find
On 09.12.2009 18:58, michal wrote:
Keith Whitwell pisze:
On Wed, 2009-12-09 at 09:16 -0800, michal wrote:
Hi all,
I would like to merge this branch back to master this week. If anoyone
could test if the build works on his/her system, it would be nice.
Thanks.
Michal,
Can you
On 09.12.2009 18:16, michal wrote:
Hi all,
I would like to merge this branch back to master this week. If anoyone
could test if the build works on his/her system, it would be nice.
Good stuff!
Looks like only scons build system is working though.
Roland
On 08.12.2009 15:55, michal wrote:
This branch simplifies pipe/p_format.h by making enum pipe_format what
it should have been -- an enum.
As a result there is no extra information encoded in it and one needs to
use auxiliary/util/u_format.h to get that info instead. Linking to the
On 08.12.2009 16:49, michal wrote:
Roland Scheidegger pisze:
On 08.12.2009 15:55, michal wrote:
This branch simplifies pipe/p_format.h by making enum pipe_format what
it should have been -- an enum.
As a result there is no extra information encoded in it and one needs to
use auxiliary
-0800, Roland Scheidegger wrote:
Hello,
I'm planning to merge gallium-strict-aliasing branch soon, which will
bring another gallium api change.
pipe_reference function has different arguments, because the old version
was pretty much not really useful for strict-aliasing compliant code
On 08.12.2009 17:37, Keith Whitwell wrote:
On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
Keith,
I think there might be some slight issue with some of the changes in the
drivers I did. In particular, I was under the impression it would be ok
to do something like
union a_union
On 08.12.2009 18:12, Roland Scheidegger wrote:
On 08.12.2009 17:37, Keith Whitwell wrote:
On Tue, 2009-12-08 at 08:31 -0800, Roland Scheidegger wrote:
Keith,
I think there might be some slight issue with some of the changes in the
drivers I did. In particular, I was under the impression
On 08.12.2009 20:57, Martin Olsson wrote:
Roland Scheidegger wrote:
Keith,
I think there might be some slight issue with some of the changes in the
drivers I did. In particular, I was under the impression it would be ok
to do something like
union a_union {
int i;
double d;
};
int f
Hello,
I'm planning to merge gallium-strict-aliasing branch soon, which will
bring another gallium api change.
pipe_reference function has different arguments, because the old version
was pretty much not really useful for strict-aliasing compliant code
(util_color_pack functions also gets an
On 04.12.2009 11:24, Kenneth Graunke wrote:
On Thursday 03 December 2009 12:47:36 Brian Paul wrote:
[snip]
I've been meaning to go over imports.[ch] and make a bunch of the
wrapper functions inlines.
A lot of the wrappers aren't needed any more. Back before valgrind I
used the
.
Roland
Jose
From: Roland Scheidegger
[srol...@vmware.com] Sent: Wednesday, December 02, 2009 23:19 To:
Jose Fonseca Cc: mesa3d-...@lists.sf.net Subject: Re: [Mesa3d-dev]
mesa/gallium strict aliasing bugs
On 02.12.2009 18:33, José Fonseca wrote
On 03.12.2009 11:17, Keith Whitwell wrote:
On Wed, 2009-12-02 at 12:46 -0800, Roland Scheidegger wrote:
On 02.12.2009 18:33, José Fonseca wrote:
I've seen strict aliasing assumption causing bugs in other gallium
components. It seems endemic to our code. Unless we actively decidee to
go
On 03.12.2009 20:55, Christoph Bumiller wrote:
Roland Scheidegger schrieb:
Hi,
I'm planning to merge gallium-noblocks branch to master soon. This api
change may affect your driver, statetracker, whatever. I _should_ have
fixed up all in tree stuff using it, but that's not a guarantee
On 03.12.2009 19:46, Matt Turner wrote:
Most of the functions in imports.c are very small, to the function
call overhead is large relative to their size. Can't we do something
like in the attached patch and move them to imports.h and mark them
static inline? Things like memcpy and memset are
Hi,
I've come across some bug (which I thought might be related to the
gallium-noblocks branch, but it's not) which caused a segfault but only
when not using debug builds. I think this is the same issue Vinson was
seeing some time ago. Looks like a impossible backtrace:
#0 st_texture_image_copy
On 02.12.2009 18:33, José Fonseca wrote:
On Wed, 2009-12-02 at 09:05 -0800, Roland Scheidegger wrote:
Hi,
I've come across some bug (which I thought might be related to the
gallium-noblocks branch, but it's not) which caused a segfault but only
when not using debug builds. I think
On 02.12.2009 18:33, José Fonseca wrote:
I've seen strict aliasing assumption causing bugs in other gallium
components. It seems endemic to our code. Unless we actively decidee to
go and chase the strict aliasing bugs now we should add
-fno-strict-aliasing to all our builds.
Hmm, actually
Hi,
I'm planning to merge gallium-noblocks branch to master soon. This api
change may affect your driver, statetracker, whatever. I _should_ have
fixed up all in tree stuff using it, but that's not a guarantee it will
still run correctly (nv50 driver was strange for instance), and
certainly if
On 02.12.2009 18:33, José Fonseca wrote:
I've seen strict aliasing assumption causing bugs in other gallium
components. It seems endemic to our code. Unless we actively decidee to
go and chase the strict aliasing bugs now we should add
-fno-strict-aliasing to all our builds.
Do we ever want
On 01.12.2009 11:16, Ian Romanick wrote:
Speaking of which... there are a bunch of conflicts merging 7.7 to
master in Galliumland. Could one of you guys take a look at it? I have
no clue what's going on over there.
Quite a few of that was due to the gallium interface changes (introduced
by
On 01.12.2009 15:35, Keith Whitwell wrote:
On Tue, 2009-12-01 at 06:31 -0800, Roland Scheidegger wrote:
On 01.12.2009 11:16, Ian Romanick wrote:
Speaking of which... there are a bunch of conflicts merging 7.7 to
master in Galliumland. Could one of you guys take a look at it? I have
no clue
On 27.11.2009 19:32, michal wrote:
Why is the MAX here smaller than for fragment samplers? Doesn't GL
require them to be the same, because GL effectively binds the same set
of sampler states in both cases?
Can you take a closer look at what the GL state tracker would have to do
to expose
Hi,
just a warning I'm planning on merging width0 branch to master tomorrow.
This is a interface change eliminating width/height/depth arrays from
pipe_texture, instead just storing base width/height/depth. In-tree
drivers/state trackers should be fixed (I think though there might be
bugs with
I'm planning to merge st_shader-varients branch to master tomorrow.
This should not adversely affect drivers, unless they rely on generics
inputs/outputs semantic_index always starting at 0 without holes
(something that they shouldn't do but it would have worked previously).
Feedback for hw
On 23.10.2009 08:37, Maciej Cencora wrote:
Hi,
as you may already know r300 classic driver is in pretty good shape these
days, but there's one thing that causes major slowdowns in many games: lack
of
hardware accelerated blit operation.
The same is true for r100/r200...
Currently all
Hmm, I'm not actually sure this will always reduce the state key size. I
think the compiler is still allowed to pad the mode_opt struct out to
whatever it likes (maybe #pragma pack(1) can prevent this), even though
maybe gcc does not.
I don't like pragmas too much, but it looks the only way to do
On 23.08.2009 01:50, Ian Romanick wrote:
Philipp Heise wrote:
Ian Romanick wrote:
Roland Scheidegger wrote:
glprogs/R200_interaction.vp
GL_PROGRAM_ERROR_STRING_ARB: line 1, char 43: error: syntax error,
unexpected $undefined
Okay. I posted a patch to bug #23457 that should fix
On 23.08.2009 01:50, Ian Romanick wrote:
Philipp Heise wrote:
Ian Romanick wrote:
Roland Scheidegger wrote:
glprogs/R200_interaction.vp
GL_PROGRAM_ERROR_STRING_ARB: line 1, char 43: error: syntax error,
unexpected $undefined
Okay. I posted a patch to bug #23457 that should fix
On 21.08.2009 20:26, Ian Romanick wrote:
All,
In the next couple hours I'm planning to merge the asm-shader-rework-1
branch to master. In my testing I have found that it passes at least as
many (and in a couple cases more) tests than the current code. One of
our internal tests runs about
On 13.08.2009 12:19, Michel Dänzer wrote:
On Wed, 2009-08-12 at 11:31 -0700, Eric Anholt wrote:
Module: Mesa Branch: master Commit:
e643bc5fc7afb563028f5a089ca5e38172af41a8 URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e643bc5fc7afb563028f5a089ca5e38172af41a8
Author: Eric Anholt
On 31.07.2009 10:26, Terry Barnaby wrote:
Hi,I have a problem with the Mesa DRI Radeon 300 driver in that I cannot use
the
blender application as the menus are not displayed correctly. See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=21774
I would like to get this fixed as I need to
On 31.07.2009 15:35, Terry Barnaby wrote:
On 07/31/2009 02:15 PM, Roland Scheidegger wrote:
On 31.07.2009 10:26, Terry Barnaby wrote:
Hi,I have a problem with the Mesa DRI Radeon 300 driver in that I cannot
use the
blender application as the menus are not displayed correctly. See bug:
https
On 31.07.2009 17:36, Terry Barnaby wrote:
I have just compiled/installed the latest drm/mesa/xf86-video-ati code from
git
under Fedora 11 on a system with an ATI Technologies Inc RV280 [Radeon 9200
PRO]
graphics board.
2D appears fine. 3D is quite broken.
gxlgears runs showing about
1 - 100 of 220 matches
Mail list logo
