Hi Brian,
The attached patches are trivial fixes to a distribution problem and
cofigure.ac. I've done a clean build test
$ make tarballs
$ tar xf MesaLib-7.7-devel.tar.gz
$ cd Mesa-7.7-devel/
$ ./configure --with-state-trackers=egl,es
$ make -j4 CC="ccache gcc"
and tested all ES1/ES2 demos.
Do
On Mon, 2010-01-04 at 10:51 -0700, Brian Paul wrote:
> Alan Hourihane wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
> >
> > Author: Alan Hour
On Tue, Jan 5, 2010 at 5:17 AM, Brian Paul wrote:
> I'm committing to the opengl-es-v2 branch now. Thanks.
Thanks. I have one or two more patches to support autotools and fix
distribution problem. I will send them shortly, and I would like to discuss
the merge plan with you.
---
On Mon, Jan 4, 2010 at 11:17 PM, Luca Barbieri wrote:
> I meant, how about having egl_g3d provide the GLX API as well as the EGL
> API?
> Of course, it will require some code in libGL.so to dispatch glX* functions
> to egl_g3d.
> That code already exists in src/mesa/drivers/x11/glxapi.c: it would
No idea.
It could be tested either with Direct3D 9 on Windows (assuming the driver
does not reject that), by modifying the Mesa source or by using Gallium
directly.
The issue is whether to have the Gallium API support it by splitting
max_anisotropy into max_mag_anisotropy or max_min_anisotropy or
http://bugs.freedesktop.org/show_bug.cgi?id=24016
--- Comment #15 from Sven Arvidsson 2010-01-04 13:42:42 PST ---
Created an attachment (id=32445)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32445)
screenshot of the menu faded to black
The menu problem seems to have somthing to do w
Chia-I Wu wrote:
> On Tue, Dec 08, 2009 at 02:25:14PM +0800, Chia-I Wu wrote:
>> On Sun, Nov 22, 2009 at 9:02 PM, Chia-I Wu wrote:
>>> This patch series replaces APIspec.txt by APIspec.xml. The new
>>> XML-based format resolves two issues with APIspec.txt
>>> * Not easy to read
>>> * Code duplica
Never had an occasion to really look and see; is there an actual example or
use-case?
Posting from a mobile, pardon my terseness. ~ C.
On Jan 4, 2010 1:07 PM, "Luca Barbieri" wrote:
Does this answer really to magnification in addition to minification?
In other words, does R300 with anisotropic
Does this answer really to magnification in addition to minification?
In other words, does R300 with anisotropic minfilter + bilinear magfilter
behave differently than anisotropic minfilter + anisotropic magfilter?
--
This
http://bugs.freedesktop.org/show_bug.cgi?id=24016
--- Comment #14 from Brian Paul 2010-01-04 13:04:32
PST ---
I've committed the patch to the 7.7 branch.
I don't know what the problem is with the menu.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
On r300, aniso definitely works and is noticeably different from bilinear.
Posting from a mobile, pardon my terseness. ~ C.
On Jan 4, 2010 12:19 PM, "Luca Barbieri" wrote:
> Note that different 3d apis have different requirements - ideally we >
should be able to choose so...
Maybe we could, in
http://bugs.freedesktop.org/show_bug.cgi?id=24016
--- Comment #13 from Sven Arvidsson 2010-01-04 12:17:46 PST ---
The warning is gone now, thanks!
The problems with the menu are still there though, so I guess that's an
unrelated bug.
--
Configure bugmail: http://bugs.freedesktop.org/use
> Note that different 3d apis have different requirements - ideally we
> should be able to choose some state which suits all of them.
> In particular, d3d10/11 have a separate filter mode for aniso (which
> applies to all of min/mag/mip filters at the same time).
> d3d9 also has special aniso filte
writes:
> On Sun, 2010-01-03 at 12:55 -0800, Kristian Høgsberg wrote:
> > On Sun, Jan 3, 2010 at 3:24 PM, José Fonseca wrote:
> > > On Sun, 2010-01-03 at 08:45 -0800, Brian Paul wrote:
> > >> 2010/1/2 Chia-I Wu :
> > >> > On Sat, Jan 02, 2010 at 07:01:02PM -0500, Kristian Høgsberg wrote:
> > >> >
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 maxi
http://bugs.freedesktop.org/show_bug.cgi?id=24016
--- Comment #12 from Brian Paul 2010-01-04 11:40:13
PST ---
Created an attachment (id=32441)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32441)
proposed patch to fix the warning/problem report
Can you try this patch?
It looks like
http://bugs.freedesktop.org/show_bug.cgi?id=24016
--- Comment #11 from Sven Arvidsson 2010-01-04 11:28:36 PST ---
Sure, the warning is now:
Mesa 7.8-devel implementation error: bad srcFormat GL_DU8DV8_ATI in extract
float data
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.c
Hi,
On Mon, Jan 4, 2010 at 10:27 AM, Zack Rusin wrote:
> On Wednesday 30 December 2009 09:07:48 Igor Oliveira wrote:
>> This patch fix some bugs found by unit tests like passing a wrong
>> device type all the devices(gpu, cpu and accelarator)
>> was being created, ignore paramValue if it is NULL
On Monday 04 January 2010 13:19:27 Brian Paul wrote:
> Keith Whitwell wrote:
> > I think this is pretty much equivalent to restricting indexing to
> > defined ranges of indexable temporaries. I'm guessing the way that
> > would work is we'd say something like:
> >
> > DECL OUT[0]
> > DECL ADDR[0]
http://bugs.freedesktop.org/show_bug.cgi?id=24016
--- Comment #10 from Brian Paul 2010-01-04 10:28:34
PST ---
Can you update your git tree and run again? I just committed a patch that'll
give more info in the "bad srcFormat" warning.
--
Configure bugmail: http://bugs.freedesktop.org/use
Brian Paul wrote:
> Keith Whitwell wrote:
>> On Mon, 2010-01-04 at 09:47 -0800, Brian Paul wrote:
>>> Christoph Bumiller wrote:
On 31.12.2009 12:05, Keith Whitwell wrote:
> Luca,
>
> This is an impressive body of work. I want to give Jose a chance to
> review the EGL/GLX exten
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> Alan Hourihane wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
>>
>> Author: Alan
Keith Whitwell wrote:
> On Mon, 2010-01-04 at 09:47 -0800, Brian Paul wrote:
>> Christoph Bumiller wrote:
>>> On 31.12.2009 12:05, Keith Whitwell wrote:
Luca,
This is an impressive body of work. I want to give Jose a chance to
review the EGL/GLX extensions before pushing, but i
http://bugs.freedesktop.org/show_bug.cgi?id=24016
--- Comment #9 from Sven Arvidsson 2010-01-04 10:14:19 PST ---
The rendering errors in the menu are still there (and the warning about an
implementation error) but the actual game no longer crashes and seems to be
playable.
I'm using git mas
Brian,
I've pulled in the latest commits to Mesa and did a recompile with
gmake.The internal compiler error with the Vega state-tracker didn't show up
this time,but I will post the output the next time it does.
Here is some additional info.I'm currently using Fedora 13 Rwahide,the gcc
versi
Basically just removing the redundant boolean return values from the
gallium draw calls. If nobody objects I'll merge this branch in the
next day or so.
Keith
--
This SF.Net email is sponsored by the Verizon Developer C
On Mon, 2010-01-04 at 09:47 -0800, Brian Paul wrote:
> Christoph Bumiller wrote:
> > On 31.12.2009 12:05, Keith Whitwell wrote:
> >> Luca,
> >>
> >> This is an impressive body of work. I want to give Jose a chance to
> >> review the EGL/GLX extensions before pushing, but in the meantime I hope
> >
Alan Hourihane wrote:
> Module: Mesa
> Branch: master
> Commit: 1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=1baaf111c8c42ed7f7218c46038f32eb51b9c6eb
>
> Author: Alan Hourihane
> Date: Mon Jan 4 17:41:49 2010 +
>
> fix overflow
>
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
Christoph Bumiller wrote:
> On 31.12.2009 12:05, Keith Whitwell wrote:
>> Luca,
>>
>> This is an impressive body of work. I want to give Jose a chance to
>> review the EGL/GLX extensions before pushing, but in the meantime I hope
>> it's ok if I make a couple of quick suggestions/requests:
>>
>> F
On Mon, 2010-01-04 at 09:39 -0800, Brian Paul wrote:
> michal wrote:
> > Hi,
> >
> > I would like to merge gallium-integer-opcodes branch to master this
> > week. This feature branch adds support for integer operations in TGSI
> > that is required by GLSL 1.30.
> >
> > In summary:
> > * add a b
michal wrote:
> Hi,
>
> I would like to merge gallium-integer-opcodes branch to master this
> week. This feature branch adds support for integer operations in TGSI
> that is required by GLSL 1.30.
>
> In summary:
> * add a bunch of opcodes operating on signed and unsigned integers,
> * add sign
STEVE555 wrote:
> Brian,
> Over the weekend,Martin-20 commited a patch to fix the build
> breakage to autoconf building and that solved my problem,I do have a slight
> problem with the Vega state-tracker.If I use gmake to build Mesa,I sometimes
> get a internal compiler error,if I use make
Brian,
Over the weekend,Martin-20 commited a patch to fix the build
breakage to autoconf building and that solved my problem,I do have a slight
problem with the Vega state-tracker.If I use gmake to build Mesa,I sometimes
get a internal compiler error,if I use make instead,the Vega state-tr
I meant, how about having egl_g3d provide the GLX API as well as the EGL
API?
Of course, it will require some code in libGL.so to dispatch glX* functions
to egl_g3d.
That code already exists in src/mesa/drivers/x11/glxapi.c: it would only
need to be passed a suitable dispatch table.
This way, you
On Mon, Jan 4, 2010 at 2:23 PM, Keith Whitwell wrote:
> Luca,
>
> Thanks for looking into this - this is a bit of a grey area for me.
>
> One question - do we need a full floating point value to represent
> max_anisotropy? What is the typical maximum value for max_anisotropy in
> hardware, and h
This is a reimplementation of the EGL_MESA_gallium extension over egl_g3d.
It is much simpler and cleaner than the older patch I posted to the list, which
should be disregarded.
GLX support is not implemented. It may be added later to an eventual GLX API
implementation over the egl_g3d core.
The
The current code revalidates based on whether width or height have changed.
This is unreliable (it may change two times, with another context having got
the buffers for the intermediate size in the meantime) and causes two DRI2
calls.
Instead, we add the notion of a drawable sequence number, whic
Currently DRI2 always calls texture_from_shared_handle on validate.
This may cause problems due if it is called multiple times on the same handle,
since multiple struct pipe_texture pointing to the same GEM buffer will be
created.
On some drivers, this results in pushbuffers being submitted with
It is implemented by adding a new depth/stencil native attachment.
While depth seems to work even without this, due to the Mesa state tracker
creating it itself, this is the way other DRI2 drivers work and might work
better in some cases.
If we pass to validate a non-existent attachment or
NATIV
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 have otherwise occurred).
>> See
STEVE555 wrote:
> Hi everyone,
> I've just pulled the latest commits for Mesa from the git
> repository today,(01,01,10).
> My configure options are:
>
> ./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
> --sbindir=/usr/sbin --datadir=/usr/share --sysconfdir=/etc
>
Given that we're going down the path of having typed operands, it would
seem that new operands (like MOVDB) make sense.
Keith
On Mon, 2010-01-04 at 05:18 -0800, Igor Oliveira wrote:
> Right,
>
> i was thinking tgsi supporting DOUBLE types. The first solution that i
> was considering is use all o
On Wednesday 30 December 2009 09:07:48 Igor Oliveira wrote:
> This patch fix some bugs found by unit tests like passing a wrong
> device type all the devices(gpu, cpu and accelarator)
> was being created, ignore paramValue if it is NULL and return
> invalid_value if paramValueSize != paramValueSize
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 have otherwise occurred).
> See the spec at
> http://www.ope
Luca,
Thanks for looking into this - this is a bit of a grey area for me.
One question - do we need a full floating point value to represent
max_anisotropy? What is the typical maximum value for max_anisotropy in
hardware, and how may levels are there? From the patch below, most
DX9-level hardw
Right,
i was thinking tgsi supporting DOUBLE types. The first solution that i
was considering is use all operations like double value. Other way is
create Double instructions like movdb ou something like that. what do
you think?
Igor
On Mon, Jan 4, 2010 at 8:35 AM, michal wrote:
> Igor Oliveir
Igor Oliveira wrote on 2010-01-04 12:49:
> Hi
>
> i was seeing the changes done by gallium-integer-opcodes the mov
> operation using dst like float type in embedded systems can not be
> slow?
>
>
Igor,
The MOV instruction always interprets the source operand as FLOAT, thus
source operand modif
Hi
i was seeing the changes done by gallium-integer-opcodes the mov
operation using dst like float type in embedded systems can not be
slow?
Igor
On Sun, Jan 3, 2010 at 4:14 PM, michal wrote:
> Hi,
>
> I would like to merge gallium-integer-opcodes branch to master this
> week. This feature bran
On Fri, 2010-01-01 at 10:13 -0800, José Fonseca wrote:
> On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote:
> > Maybe a "direct Gallium state tracker" could be added, but it would
> > require duplicating the X11/DRM setup logic in EGL and GLX.
>
> In my view Gallium isn't an interface meant
Kristian Høgsberg wrote:
> 2009/12/29 Thomas Hellstrom :
>
>> Kristian,
>>
>> I was looking at how Swapbuffers is done with DRI2 when a fake front is
>> present:
>>
>> The back buffer is copied to the real front, and then the real front is
>> copied back to the fake.
>>
>> This causes some probl
On Mon, Jan 4, 2010 at 2:24 AM, Luca Barbieri wrote:
> Yes, that's a possible way to implement this.
> However, it would artificially introduce the notion of a current context in
> Gallium.
> Also, if you mean implementing this as an egl_g3d API, it seems to me you
> would have to implement the wh
On Mon, Jan 4, 2010 at 4:24 AM, José Fonseca wrote:
> Brian is right.
> GLAPI controls symbol visibility, both on unices (i.e.,
> _attribute__((visibility("default" and windows (i.e.,
> _declspec(dllexport).
> GLAPIENTRY controls the calling convention (i.e., __stdcall presence or
> absence).
On Mon, Jan 4, 2010 at 2:24 AM, Luca Barbieri wrote:
> egl/xegl* are working for me on Nouveau NV40, after installing a
> src/gallium/winsys/xlib version of libGL.so.
> Haven't tested OpenVG.
Thanks. Great to hear that!
> egl_g3d currently requires the winsys/xlib version of libGL.so., that use
>
54 matches
Mail list logo
