Hi,
the attached patch fixes a possible crash in function draw_stencil_pixels in
mesa/state_tracker. I've also updated the list of formats we read from to
prevent an assertion failing later in the code.
This makes glean/depthStencil work on r300g and softpipe.
Best regards
Marek Olšák
From
Hi Brian,
I tried your patch and it solves the buffer-mapping issue.
I attached a new patch that fixes the clipping issue. Please, review/push.
Best regards
Marek Olšák
On Mon, Nov 2, 2009 at 6:12 PM, Brian Paul bri...@vmware.com wrote:
Marek Olšák wrote:
Hi,
the attached patch fixes
Hi Roland,
r300g doesn't use *semantic_index at all and due to this some shaders are
broken on it. Merging the branch probably can't make it worse, so go for it.
I already have fixes for this driver here and I am about to send them soon.
Marek
On Wed, Nov 25, 2009 at 4:47 AM, Roland Scheidegger
not be
able to draw a quad without visual errors.
Please review.
Best regards
Marek Olšák
From a6d16e7bce330900d496593054ec6aeb3ed51a2f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Mon, 7 Dec 2009 00:33:17 +0100
Subject: [PATCH] gallium: let drivers fallback
On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
As far as immediate verts, why don't we just add support to r300g to switch
to immediate mode for small VBOs?
Posting from a mobile, pardon my terseness. ~ C.
Corbin,
that seems reasonable, and it's the reason
On Tue, Dec 15, 2009 at 10:28 AM, Keith Whitwell kei...@vmware.com wrote:
On Mon, 2009-12-14 at 16:31 -0800, Marek Olšák wrote:
On Mon, Dec 14, 2009 at 5:42 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
As far as immediate verts, why don't we just add support to r300g to switch
On Tue, Dec 15, 2009 at 11:27 AM, Keith Whitwell kei...@vmware.com wrote:
On Tue, 2009-12-15 at 01:49 -0800, Marek Olšák wrote:
On Tue, Dec 15, 2009 at 10:28 AM, Keith Whitwell kei...@vmware.com wrote:
On Mon, 2009-12-14 at 16:31 -0800, Marek Olšák wrote:
On Mon, Dec 14, 2009 at 5:42 PM
: Marek Olšák mar...@gmail.com
Date: Sat Dec 12 23:44:02 2009 +0100
r300g: flush CS if a buffer being deleted is referenced by it
[...]
diff --git a/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
b/src/gallium/winsys/drm/radeon/core/radeon_buffer.c
index 2a8daed..76acc99 100644
--- a/src
Hi,
GL_ARB_provoking_vertex states that quads are not required to abide
the provoking vertex convention, and the actual hardware and/or driver
behavior can be queried with
GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION.
I'd like to add a new PIPE_CAP_* to query for this capability in
Gallium, as it
Hi,
I noticed that gallium/auxiliary/util/u_format.csv contains some weird
swizzling, for example see this:
$ grep zyxw u_format.csv
PIPE_FORMAT_A8R8G8B8_UNORM, arith , 1, 1, un8 , un8 , un8 , un8 ,
zyxw, rgb
PIPE_FORMAT_A1R5G5B5_UNORM, arith , 1, 1, un5 , un5 , un5 , un1 ,
zyxw,
I am not very fond of the idea having another layer of function-call
indirections and state management between a driver and a state tracker. I
kinda succeed in making the failover driver work with some hacks and
limitations (e.g. no textures). Even if I use it as a simple pass-through
driver, it
Zack,
to be honest, Direct3D 11 can report geometry shaders are not supported
through so-called feature levels. There are six levels to my knowledge (9_1,
9_2, 9_3, 10_0, 10_1, 11_0). i915 is 9_1, R300 is 9_2, R500 is 9_3, and so
on. Direct3D 11 is indeed accelerated on those pieces of hardware
It was NOT intended to be a performance optimization, it's a fix. I added it
because kernel would have rejected the command stream if everything had been
culled by scissoring.
Marek
On Mon, Jan 11, 2010 at 4:39 PM, Corbin Simpson
mostawesomed...@gmail.comwrote:
Pardon the subject pun, it was
Hi Luca,
I think this is not necessary and fixing the rasterizer setup in the driver
would by better than fixing the state tracker.
In r300g, we dynamically allocate rasterizer units based on vertex shader
outputs. If the vertex shader uses slots 1, 5, 20, 100, the driver maps
them to units
Hi Brian,
On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul bri...@vmware.com wrote:
The second patch enables hardware-accelerated CopyTex[Sub]Image in cases
when the RGB and RGBA destination formats are used regardless of source
formats. The idea is that if the colorbuffer is of RGB or RGBA
Yes, your patch solves my problem. Thanks.
Marek
On Wed, Jan 20, 2010 at 2:00 AM, Brian Paul bri...@vmware.com wrote:
Marek Olšák wrote:
Hi Brian,
On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul bri...@vmware.com mailto:
bri...@vmware.com wrote:
The second patch enables hardware
Hi Corbin,
On Sat, Jan 30, 2010 at 1:06 PM, Corbin Simpson
mostawesomed...@gmail.comwrote:
5) ... Also, on the topic of framebuffers, is
it okay to refuse to render if no MRTs or Z buffer are present?
Do you mean color-only and depth-only rendering? This is a must. Shadow
mapping heavily
On Sun, Jan 31, 2010 at 1:37 AM, Roland Scheidegger srol...@vmware.comwrote:
7) Is there more information on the dual-source blend modes? I'm not
sure if I can do them; might have to bug AMD for the register values.
I bet R300 can't do these modes. It's only a Direct3D 10.0 feature,
On Mon, Feb 8, 2010 at 6:48 PM, Eric Anholt e...@anholt.net wrote:
On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák mar...@gmail.com wrote:
The attached patch series relaxes precision requirements for 6 tests to
pass
on r300g.
Please review/push.
Have you tried getting the glean
Hi,
I noticed that quite a lot of piglit tests fail with swrast and softpipe. I
was asked for sending my stats to ML so that people working on the software
rasterizers are aware of that (I guess they already know). Please see this
page:
http://storm.unas.cz/drivers_compared/
The parser tests
, disabling it is
preferable. Could you please push the first one if there are no objections?
Brian,
Could you please push the second one into glean if there are no objections?
-Marek
On Thu, Feb 11, 2010 at 1:42 AM, Eric Anholt e...@anholt.net wrote:
On Sun, 7 Feb 2010 05:38:01 +0100, Marek
=fc427d23439a2702068209957f08990ea29fe21b
Author: Marek Olšák mar...@gmail.com
Date: Fri Feb 19 04:23:06 2010 +0100
r300g: remove L8_UNORM from colorbuffer formats
Not renderable in OpenGL anyway.
The Xorg state tracker uses it though.
--
Earthling Michel Dänzer
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every texture
format except SCALED ones, a few regressions have showed up. This patch
Hi,
the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
support this extension. The drivers reporting support of
PIPE_CAP_INDEP_BLEND_ENABLE are not affected by this patch.
Please review.
Marek
From
On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul brian.e.p...@gmail.com wrote:
On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote:
Hi,
the attached patch modifies st/dri to not enable EXT_draw_buffers2 by
default because r300g and most probably even some other drivers can't
Fonseca wrote:
On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
Hi José,
the attached patch fixes incorrect swizzles in u_format.csv. There are
basically just 2 drivers which depend on the swizzles in this table:
llvmpipe and r300g. Since r300g started supporting pretty much every
On Tue, Feb 23, 2010 at 2:49 AM, Marek Olšák mar...@gmail.com wrote:
On Mon, Feb 22, 2010 at 4:23 PM, Brian Paul brian.e.p...@gmail.comwrote:
On Sun, Feb 21, 2010 at 8:00 AM, Marek Olšák mar...@gmail.com wrote:
Hi,
the attached patch modifies st/dri to not enable EXT_draw_buffers2
We actually hit this assertion when we get:
FRAG
DCL IN[0], COLOR, PERSPECTIVE
0: END
See piglit/glsl-bug-22603.
-Marek
On Fri, Feb 26, 2010 at 10:18 AM, Corbin Simpson
mostawesomed...@gmail.comwrote:
Module: Mesa
Branch: master
Commit: e5c691f445e1c02e6e2f75b817b13d7024f7a3a6
URL:
Hi,
S3TC shouldn't be advertised without the external lib and the attached patch
fixes that. Please review.
-Marek
From 94c58ff449b3818a378ad4ab5787151bc0a9ea6f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sat, 27 Feb 2010 03:20:58 +0100
Subject:
OK thanks, I pushed what you suggested.
-Marek
On Sat, Feb 27, 2010 at 9:44 PM, José Fonseca jfons...@vmware.com wrote:
On Sat, 2010-02-27 at 09:15 -0800, Marek Olšák wrote:
Hi,
S3TC shouldn't be advertised without the external lib and the attached
patch fixes that. Please review.
Hi
On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse gli...@freedesktop.orgwrote:
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
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
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 mar...@gmail.com 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
On Tue, Mar 2, 2010 at 10:20 PM, Luca Barbieri l...@luca-barbieri.comwrote:
On Tue, Mar 2, 2010 at 10:00 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
FYI r300 only supports 24 interpolators: 16 linear and 8 perspective.
(IIRC; not in front of the docs right now.) r600 supports 256
I can see this extension in ATI Catalyst 9.3.
-Marek
On Sat, Mar 6, 2010 at 1:16 AM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 744994a9c6b972a737e432cf1b699f232e2c5bfd
URL:
The attached patches change softpipe and llvmpipe so that they never provoke
the first vertex for quads. Please review. I think that these and the
Corbin's one could be pushed by now, couldn't they?
-Marek
On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul bri...@vmware.com wrote:
Corbin Simpson
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 st/mesa.
Here's the branch:
, 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.
* The inability to disable extensions in pipe_screen::get_param because
st/dri
Yes, this is a known issue. The problem is that GL_RGBA and GL_BGRA map to
PIPE_FORMAT_R8G8B8A8 (RGBA) and PIPE_FORMAT_A8R8G8B8 (ARGB), respectively,
which is wrong. The attached patch fixes it for r300g but breaks other
drivers which depend on Draw (softpipe, llvmpipe). The reason is that Draw
Also I've fixed GL_RGBA in master so now only GL_BGRA remains unresolved...
On Tue, Mar 9, 2010 at 1:29 AM, Tom t...@riseup.net wrote:
Hi people,
With the r300g driver (git ~today) drawing tris with color pointer like so:
glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(struct vtx_data), blah);
I second that. The commit breaks 6 glean tests (api2, clipFlat, fragProg1,
occluQry, pointAtten, texCombine4) with r300g.
-Marek
On Wed, Mar 10, 2010 at 10:50 PM, Luca Barbieri l...@luca-barbieri.comwrote:
In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts
commit
On Thu, Mar 11, 2010 at 4:41 PM, Luca Barbieri l...@luca-barbieri.comwrote:
I've looked into the issue, and found a workaround by looking at what
st_renderbuffer_alloc_storage (which is called to create the depth
buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.
Adding:
if(ctx)
Please see this commit:
http://cgit.freedesktop.org/~mareko/mesa/commit/?id=177a4432aa88fc68d83895ae71b7ad2c86a1e7e3
Subject: [PATCH] gallium: fix BGRA vertex color swizzles
The mapping for vertex_array_bgra:
(gl - st - translate)
GL_RGBA - PIPE_FORMAT_R8G8B8A8 (RGBA) - no swizzle (XYZW)
GL_BGRA
On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek sedat.di...@googlemail.comwrote:
Hi,
the last days I was testing Alex Deucher's power-management-2 patches
for radeon OSS driver.
While testing I saw that especially r300g dri/statetracker with
OpenArena have problems with mesa 7.8/master GIT
Please do git pull --rebase origin instead of git pull origin to avoid
Merge branch 'master' of ... commits.
-Marek
On Sun, Mar 21, 2010 at 2:40 PM, George Sapountzis gsapount...@gmail.comwrote:
That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a
pristine build. I reverted
Fixed in master without requiring new libdrm.
-Marek
On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek sedat.di...@googlemail.comwrote:
Fixes here latest issues with mesa master GIT [1].
--
Sedat
[1] http://marc.info/?l=mesa3d-devm=126934502904478w=2
I've updated the TODO list with the stuff from my private one, in case you
guys think there are too few things to do. ;)
http://dri.freedesktop.org/wiki/R300ToDo?action=diff
-Marek
On Tue, Mar 23, 2010 at 8:16 AM, Corbin Simpson
mostawesomed...@gmail.comwrote:
On Tue, Mar 23, 2010 at 12:13
On Tue, Mar 23, 2010 at 8:46 PM, Tom Stellard tstel...@gmail.com wrote:
On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard tstel...@gmail.com
wrote:
Thanks for the information.
After spending some time learning about the
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 explanation, and please review.
-Marek
From
On Tue, Mar 30, 2010 at 7:09 AM, Tom Stellard tstel...@gmail.com wrote:
On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote:
From the driver point of view, we don't have to work on the GLSL compiler
itself. The Mesa state tracker compiles GLSL to an assembler-like
language
On Tue, Mar 30, 2010 at 10:26 AM, Nicolai Haehnle nhaeh...@gmail.comwrote:
On Tue, Mar 30, 2010 at 8:13 AM, Marek Olšák mar...@gmail.com wrote:
Another idea was to convert TGSI to a SSA form. That would make unrolling
branches much easier as the Phi function would basically become a linear
There's something fishy in u_upload_mgr, could you please review the first
two patches here?
http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources
With this, r300g works again.
-Marek
On Fri, Apr 2, 2010 at 4:17 PM, Roland Scheidegger srol...@vmware.comwrote:
I'm planning on
On Sun, Apr 4, 2010 at 12:10 AM, Zack Rusin za...@vmware.com wrote:
I thought the initial proposal was likely a lot more feasible for a GSOC
(of
course there one has to point out that Mesa's GLSL compiler already does
unroll loops and in general simplifies control-flow so the points #1 and #2
On Sat, Apr 3, 2010 at 9:31 AM, Tom Stellard tstel...@gmail.com wrote:
1. Enable branch emulation for Gallium drivers:
The goal of this task will be to create an optional optimization pass
over the TGSI code to translate branch instructions into instructions
that are supported by cards
On Sun, Apr 4, 2010 at 1:07 AM, Luca Barbieri luca.barbi...@gmail.comwrote:
So basically the r300 optimization work looks doomed from the
beginning to be eventually obsoleted.
Please consider there are hw-specific optimizations in place which I think
no other compiler framework provides, and
On Sun, Apr 4, 2010 at 6:14 AM, Tom Stellard tstel...@gmail.com wrote:
On Sun, Apr 04, 2010 at 01:09:51AM +0200, Marek Olšák wrote:
Since Nicolai has already implemented the branch emulation and some other
optimizations, it would be nice to take over his work. I tried to use the
branch
Hi devs,
I (and Luca mostly) have made some simple patches which add
GL_ARB_half_float_vertex to Gallium.
Author: Marek Olšák mar...@gmail.com
r300g: enable half float vertex
st/mesa: query for half float vertex support
Author: Luca Barbieri l...@luca-barbieri.com
st/mesa: half
On Sun, Apr 4, 2010 at 9:41 PM, Luca Barbieri luca.barbi...@gmail.comwrote:
There was some talk about doing the query with a vertex buffer target
for is_format_supported.
Does it mean there will be format fallbacks? Because dword-unaligned but
still pretty common (i.e. GL1.1) vertex formats
On Sun, Apr 4, 2010 at 10:28 PM, Luca Barbieri luca.barbi...@gmail.comwrote:
Does it mean there will be format fallbacks? Because dword-unaligned but
still pretty common (i.e. GL1.1) vertex formats aren't supported by r300,
most often we hit R16G16B16. What will happen when
Hi devs,
this extensions is extensively used in Wine for obvious performance reasons
and is quite popular in the GL community, therefore we should advertise it.
All needed code seems to be already in mesa/main, so unless I overlooked
something, the patch below is sufficient. Any comments, please?
On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell kei...@vmware.com wrote:
On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote:
On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote:
There's something fishy in u_upload_mgr, could you please review the
first two patches here?
http
On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell kei...@vmware.com wrote:
OK, it seems like quite a few cases had migrated to the new
buffer_map_range() behaviour. I've looked at all I can find and moved
them back to the old behaviour.
glean is passing now on softpipe.
There's now an
On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.comwrote:
This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
Compiz shows dark screen.
(Using nouveau drivers)
Without this commit compiz works almost perfectly.
The error messages from compiz:
On Mon, May 3, 2010 at 1:57 PM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote:
I am trying to understand the s3tc init code as nv50 gallium has a
problem with that.
It looks like some drivers (r300g and llvmpipe) actually inits s3tc in
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 formats is:
formats for which copying
On Mon, Sep 6, 2010 at 9:57 PM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2010-09-06 at 10:22 -0700, Marek Olšák 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
On Fri, Dec 17, 2010 at 4:32 PM, Brian Paul bri...@vmware.com wrote:
Christoph,
I don't see a patch for the st/mesa program translation code to check
that we don't exceed the limit. Were you doing to take care of that too?
I guess we're assuming that the max number of generic inputs == max
There won't be any other way. It should be the Linux distributors' decision
whether their users can use it or not.
Marek
On Fri, Apr 1, 2011 at 5:14 PM, Philipp Klaus Krause p...@spth.de wrote:
Am 01.04.2011 15:56, schrieb Marek Olšák:
Hi,
please read on.
This patch series adds
On Sun, Apr 24, 2011 at 1:15 AM, Dave Airlie airl...@gmail.com wrote:
Hi Brian,
st/mesa: check image size before copy_image_data_to_texture()
This causes a regression with NPOT textures in fbo-generate-mipmaps on
r600g.
FWIW r300g and softpipe are broken too. The issue seems to be
69 matches
Mail list logo
