https://bugs.freedesktop.org/show_bug.cgi?id=31159
Marek Olšák changed:
What|Removed |Added
Summary|shadow problem in 0ad game |swrast: shadow problem in
https://bugs.freedesktop.org/show_bug.cgi?id=31159
--- Comment #8 from Philip Taylor 2011-03-07 18:53:48 PST ---
(In reply to comment #5)
> Does this bug report only pertain to the softpipe driver?
No - comment #0 reported it on r300g, and comment #1 on swrast, and also it
broke on llvmpipe. (I
https://bugs.freedesktop.org/show_bug.cgi?id=31159
--- Comment #7 from Marek Olšák 2011-03-07 18:23:31 PST ---
(In reply to comment #6)
> (In reply to comment #1)
> > I was looking into this issue and I wasn't able to find the cause. I guess
> > there is a bug in the texenv program code, because
https://bugs.freedesktop.org/show_bug.cgi?id=31159
--- Comment #6 from Brian Paul 2011-03-07 18:02:39 PST
---
(In reply to comment #1)
> I was looking into this issue and I wasn't able to find the cause. I guess
> there is a bug in the texenv program code, because both swrast and gallium
> fail,
https://bugs.freedesktop.org/show_bug.cgi?id=31159
--- Comment #5 from Brian Paul 2011-03-07 18:01:24 PST
---
This also fixes the piglit depth-tex-compare test! Neither softpipe nor
llvmpipe were clamping the texture coordinate to [0,1], per the spec. llvmpipe
still doesn't pass depth-tex-comp
https://bugs.freedesktop.org/show_bug.cgi?id=31159
--- Comment #4 from Philip Taylor 2011-03-07 16:00:16 PST ---
Created an attachment (id=44215)
View: https://bugs.freedesktop.org/attachment.cgi?id=44215
Review: https://bugs.freedesktop.org/review?bug=31159&attachment=44215
clamp in sample_co
https://bugs.freedesktop.org/show_bug.cgi?id=31159
--- Comment #3 from Brian Paul 2011-03-07 15:27:56 PST
---
(In reply to comment #2)
[...]
> Looking at softpipe's sp_tex_sample.c, the p[] values passed into
> sample_compare are often larger than 1.0, so it seems to me that something is
> faili
https://bugs.freedesktop.org/show_bug.cgi?id=31159
Philip Taylor changed:
What|Removed |Added
CC||exc...@gmail.com
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=31159
--- Comment #2 from Philip Taylor 2011-03-07 15:14:38 PST ---
I see this bug with softpipe, but not with i965 (non-Gallium).
I don't have a simple test case, but I've observed the problem in the game is
where parts of the terrain are outside the
On Mon, Mar 7, 2011 at 11:16 PM, Brian Paul wrote:
> On 03/07/2011 02:46 PM, Ian Romanick wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 03/07/2011 07:16 AM, Brian Paul wrote:
>>
>>> On 03/05/2011 09:26 PM, Marek Olšák wrote:
>>>
RenderTexture doesn't have to be called
On 03/07/2011 02:46 PM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/07/2011 07:16 AM, Brian Paul wrote:
On 03/05/2011 09:26 PM, Marek Olšák wrote:
RenderTexture doesn't have to be called in invalidate_rb, I guess.
---
The patch looks good but there's one simple op
Looks good. Though, if we someday get a compressed format that
encodes normalized values as ushorts or uints this would fail.
-Brian
On 03/07/2011 12:40 PM, Marek Olšák wrote:
A follow-up patch is attached.
Marek
On Mon, Mar 7, 2011 at 4:45 PM, Brian Paul mailto:bri...@vmware.com>> wrote:
Looks good.
-Brian
On 03/07/2011 12:01 PM, Marek Olšák wrote:
A new patch is attached.
Marek
On Mon, Mar 7, 2011 at 4:16 PM, Brian Paul mailto:bri...@vmware.com>> wrote:
On 03/05/2011 09:26 PM, Marek Olšák wrote:
RenderTexture doesn't have to be called in invalidate_rb, I guess.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/07/2011 07:16 AM, Brian Paul wrote:
> On 03/05/2011 09:26 PM, Marek Olšák wrote:
>> RenderTexture doesn't have to be called in invalidate_rb, I guess.
>> ---
>
> The patch looks good but there's one simple optimization that could be
> made. If
https://bugs.freedesktop.org/show_bug.cgi?id=31391
Jerome Glisse changed:
What|Removed |Added
Summary|Heroes of Newerth crashes |[RADEON:R600C] heroes of
A follow-up patch is attached.
Marek
On Mon, Mar 7, 2011 at 4:45 PM, Brian Paul wrote:
> On 03/06/2011 08:28 PM, Marek Olšák wrote:
>
>> softpipe passes all tests.
>> ---
>> src/mesa/state_tracker/st_extensions.c | 21
>> src/mesa/state_tracker/st_format.c | 54
>>
A new patch is attached.
Marek
On Mon, Mar 7, 2011 at 4:16 PM, Brian Paul wrote:
> On 03/05/2011 09:26 PM, Marek Olšák wrote:
>
>> RenderTexture doesn't have to be called in invalidate_rb, I guess.
>> ---
>>
>
> The patch looks good but there's one simple optimization that could be
> made. If
On Mon, Mar 7, 2011 at 6:12 PM, Thomas Hellstrom wrote:
> On 03/07/2011 05:55 PM, Marek Olšák wrote:
>
> Thank you very much for looking into this. It looks good to me, but it
> still doesn't fix bug 34378 (tested with sauerbraten), so the second hunk
> shouldn't be committed yet.
>
>
> Ouch. The
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=34378
---
src/mesa/vbo/vbo_exec_array.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 5818b13..98d6bad 100644
--- a/src/mesa/vbo/vbo_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/2011 03:47 PM, Jon Severinsson wrote:
> As you are about to introduce --enable-patented for floating point textures,
> I thought the same functionality should be used for s3tc support.
>
> This patch series does so by importing the code from
On Mon, 2011-03-07 at 18:52 +0100, Marek Olšák wrote:
> > 6) Pixel buffer objects
> > >
> > > It woud be nice to have hardware-accelerated PBO copy in Gallium.
> > > Would
> > > resource_copy_region be a good candidate for this, where one of
> the
> > > arguments would be PIPE_BUFFER and the other
On Mon, Mar 7, 2011 at 11:38 AM, Keith Whitwell wrote:
> On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
> >
> > Hi,
> >
> > I have several questions about Gallium. Some of them are about
> > undocumented
> > stuff, others are just little things from the top of my head. Please
> > consider
--enable-float-formats should be fine.
Stop messing with S3TC. I think things like my previous attempt to
language-lawyer S3TC compatibility in without any patented code are a
better use of time than silly patches to shoehorn it in to the
detriment of the rest of us.
On Mon, Mar 7, 2011 at 3:49 A
On 03/07/2011 05:55 PM, Marek Olšák wrote:
Thank you very much for looking into this. It looks good to me, but it
still doesn't fix bug 34378 (tested with sauerbraten), so the second
hunk shouldn't be committed yet.
Ouch. The problem is that without the second hunk, redefine_user_buffers
will
Thank you very much for looking into this. It looks good to me, but it still
doesn't fix bug 34378 (tested with sauerbraten), so the second hunk
shouldn't be committed yet.
Marek
On Mon, Mar 7, 2011 at 11:24 AM, Thomas Hellstrom wrote:
> st->user_vb[attr] was always pointing to the same user vb,
I have been having no intentions to merge the draw, softpipe, and llvmpipe
commits (assuming the floating2 merge will ever happen). Those are for you
guys to decide if you want them or not.
Marek
On Mon, Mar 7, 2011 at 9:41 AM, Jose Fonseca wrote:
> Ok. Thanks.
>
> My comments to Luca concernin
On 03/06/2011 08:28 PM, Marek Olšák wrote:
softpipe passes all tests.
---
src/mesa/state_tracker/st_extensions.c | 21
src/mesa/state_tracker/st_format.c | 54 ++-
src/mesa/state_tracker/st_gen_mipmap.c |4 ++-
3 files changed, 76 insertio
On 03/07/2011 03:38 AM, Keith Whitwell wrote:
On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
7) Stippling and smoothing
Would anyone be against removing these two from the Gallium interface
and
fully implementing them in st/mesa? It's not like any of the radeon
people
wants to implemen
On 03/05/2011 09:26 PM, Marek Olšák wrote:
RenderTexture doesn't have to be called in invalidate_rb, I guess.
---
The patch looks good but there's one simple optimization that could be
made. If glRenderBufferStorage() is called with a new width/height
but the internalFormat stays the same, w
Isn't this PIPE_USAGE_STREAM ?
Keith
On Sat, 2011-03-05 at 17:54 +0100, Jakob Bornecrantz wrote:
> Hi all
>
> Short and simple patch series attached.
>
> Some drivers can treat one shot resources differently then resources
> that are expected to be used several times. Add a usage flag to allow
With some detours I finally arrived here.
I have a need out of a commercial project that may lead into some extensions
within AIGLX and Mesa. I'm going to describe the problem and I'm open for
whatever comes to your mind, even alternative approaches. If we (from a
technical perspective you folk
Nice catch.
Jose
On Mon, 2011-03-07 at 02:24 -0800, Thomas Hellstrom wrote:
> st->user_vb[attr] was always pointing to the same user vb, regardless
> of the value of attr. Together with reverting the temporary workaround
> for bug 34378, and a fix in the svga driver, this fixes googleearth on svg
At Mon Mar 7, 2011 at 09:59:08, Jose Fonseca wrote:
> First, I don't agree with a one-size-fits-all enable-patented flag at all.
Would something like --enable-patented=floating,s3tc (with plain --enable-
patented enabling all of it for those of us in jurisdictions without swpat)
work for you?
At
2011/3/7 Dave Airlie :
> On Mon, Mar 7, 2011 at 7:06 PM, Xavier Bestel wrote:
>> On Mon, 2011-03-07 at 00:59 -0800, Jose Fonseca wrote:
>>> Your argument that we need a flag to enable everything is not true, as
>>> a single patent does not apply uniformly to all drivers.
>>
>> Except in nearly all
On Mon, 2011-03-07 at 20:47 +1000, Dave Airlie wrote:
> On Mon, Mar 7, 2011 at 3:42 AM, Marek Olšák wrote:
> > Hi,
> >
> > I have several questions about Gallium. Some of them are about undocumented
> > stuff, others are just little things from the top of my head. Please
> > consider these as thin
On Mon, Mar 7, 2011 at 3:42 AM, Marek Olšák wrote:
> Hi,
>
> I have several questions about Gallium. Some of them are about undocumented
> stuff, others are just little things from the top of my head. Please
> consider these as things I may do when time allows.
>
>
> 1) Flush flags
>
> Which PIPE_
On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
>
> Hi,
>
> I have several questions about Gallium. Some of them are about
> undocumented
> stuff, others are just little things from the top of my head. Please
> consider these as things I may do when time allows.
>
>
> 1) Flush flags
>
>
st->user_vb[attr] was always pointing to the same user vb, regardless
of the value of attr. Together with reverting the temporary workaround
for bug 34378, and a fix in the svga driver, this fixes googleearth on svga.
Signed-off-by: Thomas Hellstrom
---
src/mesa/state_tracker/st_draw.c |6 ++
On Mon, Mar 7, 2011 at 7:06 PM, Xavier Bestel wrote:
> On Mon, 2011-03-07 at 00:59 -0800, Jose Fonseca wrote:
>> Your argument that we need a flag to enable everything is not true, as
>> a single patent does not apply uniformly to all drivers.
>
> Except in nearly all countries that's exactly what
I was building mesa following the tutorial for wayland:
http://wayland.freedesktop.org/building.html and it was failing
because EGL/egl.h could not be found for some file in wayland-drm. The
patch adds the appropriate include folder.
The repo is here: git://anongit.freedesktop.org/mesa/mesa
Regar
With some detours I finally arrived here.
I have a need out of a commercial project that may lead into some extensions
within AIGLX and Mesa. I'm going to describe the problem and I'm open for
whatever comes to your mind, even alternative approaches. If we (from a
technical perspective you folk
On Mon, 2011-03-07 at 00:59 -0800, Jose Fonseca wrote:
> Your argument that we need a flag to enable everything is not true, as
> a single patent does not apply uniformly to all drivers.
Except in nearly all countries that's exactly what we want: just one
flag to enable all features because we don
First, I don't agree with a one-size-fits-all enable-patented flag at all.
It should be one flag per patent, to give the opportunity for companies to
license patents individually: imagine a company making an embedded device with
a mesa 3d driver which uses patented feature A but needs no patente
Ok. Thanks.
My comments to Luca concerning llvmpipe changes still hold true -- this is not
how I want this to be implemented in llvmpipe and I'd prefer to see the
llvmpipe changes backed out. I don't want the 99% common case (bgra8 unorm) to
be slower, just to cover the 1% (everything else).
O
On Sam, 2011-03-05 at 12:57 +0100, Christian König wrote:
> Am Donnerstag, den 03.03.2011, 14:54 +0100 schrieb Michel Dänzer:
> > That fixes the worst problem, some vertices being stuck in the top left
> > corner. However, the parts of Aero that are supposed to look 'smoky'
> > still aren't but ar
45 matches
Mail list logo
