0004-Change-some-int64_t-s-to-uint64_t-s-to-match-CARD64.patch
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, an
0006-Add-programs-to-.gitignore-in-redbook.patch
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune ap
0001-Grammar-and-spelling-fixes.patch
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications
0005-Add-programs-to-.gitignore-in-xdemos.patch
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune app
This change:
commit d888bbc45a84946cafb4f4d2c89681a580cd89bc
Author: Brian Paul
Date: Tue Nov 17 13:39:13 2009 -0700
progs/xdemos: added -lX11 -lpthread for GNU gold linker
breaks the build if you are building under a specific path prefix
(say, /opt/XORG) and you have an existing X11 ins
0003-Add-L-libdir-for-xdemos-and-egl-so-that-the-right.patch
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and
Luc Verhaegen.
>From 6b67397898003c86d7d1b5bc7f4e9f898ec90e14 Mon Sep 17 00:00:00 2001
From: Luc Verhaegen
Date: Fri, 12 Mar 2010 08:35:22 +0100
Subject: [PATCH] dri/r700: include shader/programopt.h instead of programopt.c.
---
src/mesa/drivers/dri/r600/r700_vertprog.c |2 +-
1 files change
On Fri, Mar 12, 2010 at 12:20 PM, Jakob Bornecrantz
wrote:
> On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu wrote:
>> On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu wrote:
>>> This patch series adds st_api interface to st/mesa and st/vega, and
>>> switch st/egl and st/glx from st_public interface to th
On Fri, Mar 12, 2010 at 12:07 PM, Jakob Bornecrantz
wrote:
> On Fri, Mar 12, 2010 at 2:12 AM, Chia-I Wu wrote:
>> On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz wrote:
>>> Thanks for doing this Chia-I, also a very excellent summary. Last time we
>>> talked about st_api IIRC we both agreed th
On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu wrote:
> On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu wrote:
>> This patch series adds st_api interface to st/mesa and st/vega, and
>> switch st/egl and st/glx from st_public interface to the new interface.
> I've pushed most of the this patch series to g
On Fri, Mar 12, 2010 at 10:16 AM, Chia-I Wu wrote:
> On Thu, Mar 11, 2010 at 11:45 PM, Keith Whitwell wrote:
>> On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
>>> Thanks for testing the patches. I will have a look at the segfault
>>> tomorrow.
>>> I haven't tried llvmpipe. Does softpipe a
On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu wrote:
> This patch series adds st_api interface to st/mesa and st/vega, and
> switch st/egl and st/glx from st_public interface to the new interface.
I've pushed most of the this patch series to gallium-st-api. I'd like to have
this topic branch focus
On Thu, Mar 11, 2010 at 11:45 PM, Keith Whitwell wrote:
> On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
>> Thanks for testing the patches. I will have a look at the segfault tomorrow.
>> I haven't tried llvmpipe. Does softpipe also get the rendering error?
> No, purely llvmpipe.
I've fixed
On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz wrote:
> Thanks for doing this Chia-I, also a very excellent summary. Last time we
> talked about st_api IIRC we both agreed that the way we implemented EGLImage
> was wrong. However I think that we have waited long enough to move the state
> trac
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_B
http://bugs.freedesktop.org/show_bug.cgi?id=27012
Jos van Wolput changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On Wed, Mar 10, 2010 at 7:11 AM, Brian Paul wrote:
>>> get_arrays_bounds: Handling 2 attrs
>>> attr 0: stride 16 size 12 start (nil) end 0xfffc
>>> attr 1: stride 16 size 4 start 0xc end (nil)
>>> buffer range: (nil) 0xfffc range -4 max index 4294967295
>
> Can you post the patch you used
On Thu, Mar 11, 2010 at 4:41 PM, Luca Barbieri wrote:
> 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) ctx->NewState |= _NEW_BUFFE
Hi keith,
Thank you very much for putting my mind at rest.I have to admit
I was sweating a bit,lol! I'm might try out the gallium-sampler-view branch
a bit later.
Regards,
STEVE555
Keith Whitwell-4 wrote:
>
> I actually merged the sw-api-2 branch to master & then deleted
I actually merged the sw-api-2 branch to master & then deleted the
branch. Sorry if I surprised you - just trying to avoid having
hundreds of old, dead branches cluttering up the repository. Usually
after a few weeks go by it's hard to remember which branches are still
active and which can be de
Hi guys,
I applied the patch using git apply on the Mesa master branch (I
was getting the same on there also),for some reason,Kompare wasn't doing
it's job properly. The reason I did it on there was because I looked at the
branches on cgit,and Keith's gallium-sw-api-2 branch has disapp
Luca Barbieri wrote:
> Shouldn't
>
> _mesa_add_renderbuffer(&stfb->Base, BUFFER_FRONT_LEFT, rb);
>
> be
>
> _mesa_add_renderbuffer(&stfb->Base, surfIndex, rb);
>
> instead, since you seem to make the on-demand creation mechanism
> generic and no longer limited to the front buffer?
Yes. Fixed n
On Thu, 2010-03-11 at 13:39 -0800, Johannes Obermayr wrote:
> STEVE555 wrote:
> >If I leave out the xorg state tracker,it goes past fine until it comes up
> >with this error I posted earlier:
> >
> >gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
> >gcc -c -g -O2 -Wall -
STEVE555 wrote:
>If I leave out the xorg state tracker,it goes past fine until it comes up
>with this error I posted earlier:
>
>gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
>gcc -c -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
>-fvisibility=hidden -fno-stric
Shouldn't
_mesa_add_renderbuffer(&stfb->Base, BUFFER_FRONT_LEFT, rb);
be
_mesa_add_renderbuffer(&stfb->Base, surfIndex, rb);
instead, since you seem to make the on-demand creation mechanism
generic and no longer limited to the front buffer?
-
Michel Dänzer wrote:
> On Thu, 2010-03-11 at 11:28 -0700, Brian Paul wrote:
>> Luca Barbieri wrote:
>>> Solves the Warsow issue and seems to work.
>> OK, I think you can commit the patch to 7.8 then.
>
> Can this also be backported to mesa_7_7_branch?
Sure, if you can test it. We might want to
Mathias Gottschlag wrote:
> While trying Horde3D on nouveau I found out that Mesa rejects the
> following shader which correctly compiles on the proprietary drivers
> and, as far as I can see, seems to be correct according to the GLSL specs:
>
>
> uniform sampler2D tex;
>
> void main()
> {
>
On Thu, Mar 11, 2010 at 12:23 PM, Dan Nicholson wrote:
> On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 wrote:
>>
>> Hi Keith,
>> Here's what I did.I opened Konsole on my mesa folder.I did a git
>> pull origin to get the latest commits from master,then I did a git checkout
>> -b gallium-sw
On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 wrote:
>
> Hi Keith,
> Here's what I did.I opened Konsole on my mesa folder.I did a git
> pull origin to get the latest commits from master,then I did a git checkout
> -b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
> del
Hi Keith,
Here's what I did.I opened Konsole on my mesa folder.I did a git
pull origin to get the latest commits from master,then I did a git checkout
-b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
deleted it earlier) .I then switched to the gallium-sw-api-2 usi
Sorry, forgot to reply-all ...
Original Message
Subject:Re: [Mesa3d-dev] Gallium questions ...
Date: Thu, 11 Mar 2010 18:29:10 +0100
From: Christoph Bumiller
To: Jerome Glisse
On 11.03.2010 18:13, Jerome Glisse wrote:
> Hi all,
>
> I have been a little bit ou
http://bugs.freedesktop.org/show_bug.cgi?id=26730
Marek Olšák changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: http://bu
http://bugs.freedesktop.org/show_bug.cgi?id=26730
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
While trying Horde3D on nouveau I found out that Mesa rejects the
following shader which correctly compiles on the proprietary drivers
and, as far as I can see, seems to be correct according to the GLSL specs:
uniform sampler2D tex;
void main()
{
vec3 tex = texture2D(tex, gl_TexCoord[0].
http://bugs.freedesktop.org/show_bug.cgi?id=27007
--- Comment #3 from Søren Hauberg 2010-03-11 11:12:03 PST
---
Created an attachment (id=33962)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33962)
Output of 'glxinfo'
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?
On 11 mar 2010, at 04.15, Chia-I Wu wrote:
> Hi all,
>
> This patch series adds st_api interface to st/mesa and st/vega, and
> switch st/egl and st/glx from st_public interface to the new
> interface.
>
> Feature-wise, st_api provides a more robust multiple client APIs
> (OpenGL/OpenGL ES/OpenVG)
On Thu, 2010-03-11 at 11:28 -0700, Brian Paul wrote:
> Luca Barbieri wrote:
> > Solves the Warsow issue and seems to work.
>
> OK, I think you can commit the patch to 7.8 then.
Can this also be backported to mesa_7_7_branch?
--
Earthling Michel Dänzer |http://www.vmw
On Thu, Mar 11, 2010 at 9:13 AM, Jerome Glisse wrote:
> Also i think GLSL state that the sampler information should be defined
> at shader build time but the TGSI doesn't seems to provide those, for
> r600 i need to have a shader rewritting because of this (it's not big
> and i don't mind much and
Jerome Glisse wrote on 2010-03-11 18:13:
> Hi all,
>
> I have been a little bit out of the loop on the mesa side, thus now i am
> having a bunch of questions relating to gallium, apologies if i am asking
> for obvious thing.
>
> First in tgsi compiler there is a Dimension field (struct tgsi_dimensi
On Thu, Mar 11, 2010 at 7:10 AM, Daniel Stone wrote:
> On Thu, Mar 11, 2010 at 10:02:46AM -0500, Zack Rusin wrote:
>> On Thursday 11 March 2010 02:58:49 Tollef Fog Heen wrote:
>> > ]] Zack Rusin
>> > | BTW, replacing a mail client on the server with something that's not
>> > | compatible is not ve
Luca Barbieri wrote:
> Solves the Warsow issue and seems to work.
OK, I think you can commit the patch to 7.8 then.
-Brian
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling
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
>> al
Solves the Warsow issue and seems to work.
Thanks!
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performanc
Hi all,
I have been a little bit out of the loop on the mesa side, thus now i am
having a bunch of questions relating to gallium, apologies if i am asking
for obvious thing.
First in tgsi compiler there is a Dimension field (struct tgsi_dimension)
that i don't understand, it seems all driver are
On Wed, 2010-03-10 at 13:04 +0100, Florian Mickler wrote:
> On Sun, 07 Mar 2010 12:39:15 +0200
> Maxim Levitsky wrote:
>
> > On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote:
> > > On Sun, 07 Mar 2010 00:24:24 +0200
> > > Maxim Levitsky wrote:
> > >
> > > > On Sun, 2010-03-07 at 00:05 +
On Thu, 2010-03-11 at 08:59 -0800, Jerome Glisse wrote:
> On Thu, Mar 11, 2010 at 03:16:32PM +, Keith Whitwell wrote:
> > On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> > > Keith Whitwell wrote on 2010-03-11 14:21:
> > > > On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> > > >
> > > >>
Keith Whitwell wrote on 2010-03-11 16:16:
> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
>
>> Keith Whitwell wrote on 2010-03-11 14:21:
>>
>>> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
>>>
>>>
Hi,
I would like to merge the branch in subject this week. Thi
On Thu, Mar 11, 2010 at 03:16:32PM +, Keith Whitwell wrote:
> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> > Keith Whitwell wrote on 2010-03-11 14:21:
> > > On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> > >
> > >> Hi,
> > >>
> > >> I would like to merge the branch in subject this
Brian Paul wrote:
Luca Barbieri wrote:
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) ctx->NewState |= _NEW_BUFFERS;
at the end of st_se
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 enabled before).
>
> Someone kno
On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis
wrote:
>
> It turned out that there were two bugs in glapi. One with using
> non-exec memory and the other with using an un-relocated function
> template for entry-point generation. I put fixes at:
>
> Since we are already generating static dispat
Luca Barbieri wrote:
> 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) ctx->NewState |= _NEW_BUFFERS;
>
> at the end of st_set_fra
I've pushed a cleaned-up version of this branch to
gallium-context-transfers-2. Despite its long history, this branch is a
fairly straightforward change, moving transfers to pipe_context.
We've had to do quite a bit of work elsewhere to make this change
feasible, but having done that it's not t
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 not
Karl Schultz wrote:
> Am getting these warnings in the Windows build:
>
> 2>Compiling...
> 2>lex.yy.c
> 2>program_lexer.l(327) : warning C4244: '=' : conversion from 'double'
> to 'float', possible loss of data
> 2>program_lexer.l(331) : warning C4244: '=' : conversion from 'double'
> to 'float'
Am getting these warnings in the Windows build:
2>Compiling...
2>lex.yy.c
2>program_lexer.l(327) : warning C4244: '=' : conversion from 'double' to
'float', possible loss of data
2>program_lexer.l(331) : warning C4244: '=' : conversion from 'double' to
'float', possible loss of data
2>program_lexe
http://bugs.freedesktop.org/show_bug.cgi?id=27017
Summary: swrast not working correctly - point-wide trivial
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Prior
On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
> On Thu, Mar 11, 2010 at 7:54 PM, Keith Whitwell wrote:
> > On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
> >> This is all looking good to me. The code doesn't seem to introduce any
> >> new layering issues or introduce dependencies
On Thu, Mar 11, 2010 at 7:54 PM, Keith Whitwell wrote:
> On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
>> This is all looking good to me. The code doesn't seem to introduce any
>> new layering issues or introduce dependencies on existing ones, which
>> helps with ongoing cleanups.
>> I
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) ctx->NewState |= _NEW_BUFFERS;
at the end of st_set_framebuffer_surface seems to solve the w
On Thu, Mar 11, 2010 at 10:02:46AM -0500, Zack Rusin wrote:
> On Thursday 11 March 2010 02:58:49 Tollef Fog Heen wrote:
> > ]] Zack Rusin
> > | BTW, replacing a mail client on the server with something that's not
> > | compatible is not very social.
> >
> > Rather than assuming malice, you may as
On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> Keith Whitwell wrote on 2010-03-11 14:21:
> > On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> >
> >> Hi,
> >>
> >> I would like to merge the branch in subject this week. This feature
> >> branch allows state trackers to bind sampler views in
http://bugs.freedesktop.org/show_bug.cgi?id=27018
--- Comment #6 from Brian Paul 2010-03-11 07:22:39
PST ---
Looks like the issue is related to single buffer rendering.
Some of the tests take a -db flag to turn on double buffering. point-wide
looks OK with that flag.
Hopefully someone el
http://bugs.freedesktop.org/show_bug.cgi?id=27018
--- Comment #5 from Brian Paul 2010-03-11 07:13:51
PST ---
This demo (and the others you've filed bugs against) work fine here with swrast
built with 'make linux'. With this configuration, glxinfo reports:
OpenGL vendor string: Brian Paul
http://bugs.freedesktop.org/show_bug.cgi?id=27017
--- Comment #1 from Andrew Randrianasulu 2010-03-11 06:32:25
PST ---
Created an attachment (id=33955)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33955)
glxinfo -l
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?ta
On Thursday 11 March 2010 02:58:49 Tollef Fog Heen wrote:
> ]] Zack Rusin
> | BTW, replacing a mail client on the server with something that's not
> | compatible is not very social.
>
> Rather than assuming malice, you may assume that I was trying to fix
> something when I made that change.
I
http://bugs.freedesktop.org/show_bug.cgi?id=27017
Andrew Randrianasulu changed:
What|Removed |Added
Attachment #33956|application/octet-stream|text/plain
mime type|
http://bugs.freedesktop.org/show_bug.cgi?id=27018
--- Comment #4 from Andrew Randrianasulu 2010-03-11 06:51:20
PST ---
Note - rendering directly to fb/vram is currently way too slow on rv280/KMS
I can see for minute as demo draws itself. Composite manager speed it up
--
Configure
On Thu, 2010-03-11 at 06:21 -0800, michal wrote:
> José Fonseca wrote on 2010-03-11 14:40:
> > On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> >
> >> Hi,
> >>
> >> I would like to merge the branch in subject this week. This feature
> >> branch allows state trackers to bind sampler views inst
http://bugs.freedesktop.org/show_bug.cgi?id=27018
--- Comment #3 from Andrew Randrianasulu 2010-03-11 06:47:45
PST ---
Created an attachment (id=33959)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33959)
same glxinfo -l as in bug #27017
--
Configure bugmail: http://bugs.freedeskto
http://bugs.freedesktop.org/show_bug.cgi?id=27018
--- Comment #2 from Andrew Randrianasulu 2010-03-11 06:46:30
PST ---
Created an attachment (id=33958)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33958)
wrong rendering from swrast
--
Configure bugmail: http://bugs.freedesktop.org
http://bugs.freedesktop.org/show_bug.cgi?id=27018
--- Comment #1 from Andrew Randrianasulu 2010-03-11 06:45:33
PST ---
Created an attachment (id=33957)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33957)
correct rendering from rv280
--
Configure bugmail: http://bugs.freedesktop.or
http://bugs.freedesktop.org/show_bug.cgi?id=27018
Summary: swrast not working correctly - samples/stencil
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority
Steve,
Does the attached patch help for you?
Keith
On Wed, 2010-03-10 at 05:34 -0800, STEVE555 wrote:
> Hi Keith,
> I use these configure options:
> ./configure --prefix=/usr --enable-32-bit --enable-xcb
> --enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
> --en
http://bugs.freedesktop.org/show_bug.cgi?id=27017
--- Comment #3 from Andrew Randrianasulu 2010-03-11 06:37:35
PST ---
as i can seen in point-wide code, there sould be FOUR different colors:
static void Draw(void)
{
glClear(GL_COLOR_BUFFER_BIT);.
glDisable(GL_DEPTH_TEST);
glPoint
http://bugs.freedesktop.org/show_bug.cgi?id=27017
Andrew Randrianasulu changed:
What|Removed |Added
Attachment #33955|0 |1
is obsolete|
José Fonseca wrote on 2010-03-11 14:40:
> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
>
>> Hi,
>>
>> I would like to merge the branch in subject this week. This feature
>> branch allows state trackers to bind sampler views instead of textures
>> to shader stages.
>>
>> A sampler view obje
Keith Whitwell wrote on 2010-03-11 14:21:
> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
>
>> Hi,
>>
>> I would like to merge the branch in subject this week. This feature
>> branch allows state trackers to bind sampler views instead of textures
>> to shader stages.
>>
>> A sampler view ob
On Thu, 2010-03-11 at 05:21 -0800, Keith Whitwell wrote:
> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> > Hi,
> >
> > I would like to merge the branch in subject this week. This feature
> > branch allows state trackers to bind sampler views instead of textures
> > to shader stages.
> >
>
On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> Hi,
>
> I would like to merge the branch in subject this week. This feature
> branch allows state trackers to bind sampler views instead of textures
> to shader stages.
>
> A sampler view object holds a reference to a texture and also overrides
On Thu, 2010-03-11 at 05:21 -0800, Keith Whitwell wrote:
> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> > Hi,
> >
> > I would like to merge the branch in subject this week. This feature
> > branch allows state trackers to bind sampler views instead of textures
> > to shader stages.
> >
>
On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> Hi,
>
> I would like to merge the branch in subject this week. This feature
> branch allows state trackers to bind sampler views instead of textures
> to shader stages.
>
> A sampler view object holds a reference to a texture and also overrides
On Wed, 2010-03-10 at 13:37 +0100, Peter Hanzel wrote:
>
> I had to change this:
> src/gallium/state_trackers/egl/kms/native_kms.c
> in kms_surface_swap_buffers:
>
>if (ksurf->is_shown && kcrtc->crtc) {
> //err = drmModeSetCrtc(kdpy->fd, kcrtc->crtc->crtc_id,
> // ksurf->bac
On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
> On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
> > Hi all,
> >
> > This patch series adds st_api interface to st/mesa and st/vega, and
> > switch st/egl and st/glx from st_public interface to the new interface.
> >
> > Feature-wise,
On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
> Hi all,
>
> This patch series adds st_api interface to st/mesa and st/vega, and
> switch st/egl and st/glx from st_public interface to the new interface.
>
> Feature-wise, st_api provides a more robust multiple client APIs
> (OpenGL/OpenGL ES/
http://bugs.freedesktop.org/show_bug.cgi?id=27007
--- Comment #2 from Michel Dänzer 2010-03-11 03:24:09 PST
---
Please attach the glxinfo output.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the ass
Hi,
I would like to merge the branch in subject this week. This feature
branch allows state trackers to bind sampler views instead of textures
to shader stages.
A sampler view object holds a reference to a texture and also overrides
internal texture format (resource casting) and specifies RGBA
http://bugs.freedesktop.org/show_bug.cgi?id=27012
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, 2010-03-10 at 22:48 +0100, Johannes Obermayr wrote:
> XServer 1.7.5:
>
> I think it is this commit:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=a56da1005d30da60701e33b75d5f4f37096df060
>
> Thanks.
> Johannes
>
>
> gcc -c -I. -I../../../../src/gallium/include
> -I../../../../src
]] Zack Rusin
| On Wednesday 10 March 2010 14:59:42 Zack Rusin wrote:
| > Maybe /usr/bin/mail is broken, I'll double check it.
|
| Yea, that's it. Someone installed a new mail daemon on the
| server. We're using "-a" to specify the Content-Type header in mails,
| but the heirloom mailx that has
http://bugs.freedesktop.org/show_bug.cgi?id=27012
Summary: mesa git shows a compilation error
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
91 matches
Mail list logo
