On 11-06-20 01:22 PM, tom fogal wrote:
I am trying to get some regression tests to run in Xvfb. On my
workstation, the GL_VERSION string from this is:
1.4 (2.1 Mesa 7.7.1)
according to glxinfo. The extensions fairly clearly show 2.x features.
Is it perhaps the case that 2.1 features were a
https://bugs.freedesktop.org/show_bug.cgi?id=38508
Brian Paul changed:
What|Removed |Added
Product|Mesa|freedesktop.org
Component|Other
2011/6/20 Brian Paul :
> On 06/20/2011 05:31 PM, Stéphane Marchesin wrote:
>>
>> If possible, we want to match the hardware format to what the app uses. By
>> doing so, we avoid the need for pixel conversions and therefore greatly
>> speed
>> up texture uploads.
>> ---
>> src/mesa/state_tracker/st
On 06/20/2011 05:31 PM, Stéphane Marchesin wrote:
---
src/mesa/state_tracker/st_format.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 6f43c03..2196972 100644
--- a/src/mesa/state_track
On 06/20/2011 05:31 PM, Stéphane Marchesin wrote:
If possible, we want to match the hardware format to what the app uses. By
doing so, we avoid the need for pixel conversions and therefore greatly speed
up texture uploads.
---
src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +-
src/mesa/
https://bugs.freedesktop.org/show_bug.cgi?id=38501
Rafael Monica changed:
What|Removed |Added
CC||monr...@gmail.com
--- Comment #2 from Ra
---
src/mesa/state_tracker/st_format.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 6f43c03..2196972 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.
If possible, we want to match the hardware format to what the app uses. By
doing so, we avoid the need for pixel conversions and therefore greatly speed
up texture uploads.
---
src/mesa/state_tracker/st_atom_pixeltransfer.c |2 +-
src/mesa/state_tracker/st_cb_drawpixels.c | 10 ++-
src/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2011 05:43 PM, Dan McCabe wrote:
> Beware! Here be dragons!
>
> Up until now modyfing the GLSL compiler has been pretty straightforward.
> This is where things get interesting.
>
> Switch statement processing leverages infrastructure that wa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2011 05:43 PM, Dan McCabe wrote:
> The grammar is modified to support switch statements. Rather than follow the
> grammar in the appendix, which allows case labels to be placed ANYWHERE
> as a regular statement, we follow the development of th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2011 05:43 PM, Dan McCabe wrote:
> We now tie the grammar to the ctors of the ASTs they reference.
>
> This requires that we actually have definitions of the ctors.
>
> In addition, we also need to define "print" and "hir" methods for the AS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2011 05:43 PM, Dan McCabe wrote:
> Previously we added productions for:
> switch_body
> case_label_list
> case_statement
> case_statement_list
> Now add AST structs corresponding to those productions.
> ---
> src/glsl/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2011 05:43 PM, Dan McCabe wrote:
> Data structures for switch statement and case label are created that parallel
> the structure of other AST data.
> ---
> src/glsl/ast.h | 24
> 1 files changed, 20 insertions(+), 4
https://bugs.freedesktop.org/show_bug.cgi?id=38508
Marcin Slusarz changed:
What|Removed |Added
Attachment #48212|application/x-mspublisher |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=38508
--- Comment #1 from Marcin Slusarz 2011-06-20
15:11:21 PDT ---
Created an attachment (id=48213)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48213)
pgp key
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=38508
Summary: Account request for Marcin Ślusarz
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/2011 10:22 AM, tom fogal wrote:
> I am trying to get some regression tests to run in Xvfb. On my
> workstation, the GL_VERSION string from this is:
>
> 1.4 (2.1 Mesa 7.7.1)
>
> according to glxinfo. The extensions fairly clearly show 2.x
On 11-06-20 03:46 PM, tom fogal wrote:
Nathan Kidd writes:
On 11-06-20 02:55 PM, tom fogal wrote:
Nathan Kidd writes:
[snip]
You are correct, rendering is indirect! I was unaware that direct
vs. indirect limited *GL* features. Why is that the case, and what
can be done?
Of course, for
Nathan Kidd writes:
> On 11-06-20 02:55 PM, tom fogal wrote:
> > Nathan Kidd writes:
[snip]
> > You are correct, rendering is indirect! I was unaware that direct
> > vs. indirect limited *GL* features. Why is that the case, and what
> > can be done?
>
> Of course, for indirect rendering every g
Try the following command:
LIBGL_DEBUG=verbose glxinfo
and see what's the problem (just a few beginning lines that are new).
Have you installed mesa from sources? If so, didn't you forget about
dri drivers (in your case, swrast_dri.so)?
2011/6/20 tom fogal :
> Gustaw Smolarczyk writes:
>> Isn't
That's the way OpenGL versioning works, you could only expose some GL
base level if you support *all* of the needed extensions for this base
level. However every driver is free to expose additional extensions it
supports.
It is the applications job to enumerate the available extensions in
order to
On 11-06-20 02:55 PM, tom fogal wrote:
Nathan Kidd writes:
Both the major and minor portions of the version number are
of arbitrary length. The vendor-specific information is
optional. However, if it is present, the format and contents are
implementation specific. "
Yes, I know how the versio
Gustaw Smolarczyk writes:
> Isn't that version because it uses indirect rendering? AFAIK indirect
> limits GL version to 1.4. There is the version of X's AIGLX driver in
> parentheses, but only 1.4 features can be used.
Ahh, this is the type of caveat I was hoping to hear ;)
> But it may not be
Nathan Kidd writes:
> On 11-06-20 01:22 PM, tom fogal wrote:
> > I am trying to get some regression tests to run in Xvfb. On my
> > workstation, the GL_VERSION string from this is:
> >
> >1.4 (2.1 Mesa 7.7.1)
[snip]
> > In any case, the above version string breaks projects like GLEW
[snip]
>
Isn't that version because it uses indirect rendering? AFAIK indirect
limits GL version to 1.4. There is the version of X's AIGLX driver in
parentheses, but only 1.4 features can be used.
But it may not be the case here. Could you check wheter glxinfo says
that direct rendering is enabled?
2011/6
On Mon, 20 Jun 2011 10:59:43 -0700 (PDT), Jose Fonseca
wrote:
> With the way the corruption looked like, I would never imagine a GPU
> hang. I must have been a nasty issue to debug.
>
> I saw this issue with a netbook I have at home but I didn't had
> opportunity to verify with your fix it yet.
On 11-06-20 01:22 PM, tom fogal wrote:
I am trying to get some regression tests to run in Xvfb. On my
workstation, the GL_VERSION string from this is:
1.4 (2.1 Mesa 7.7.1)
according to glxinfo. The extensions fairly clearly show 2.x features.
Is it perhaps the case that 2.1 features were a
With the way the corruption looked like, I would never imagine a GPU hang. I
must have been a nasty issue to debug.
I saw this issue with a netbook I have at home but I didn't had opportunity to
verify with your fix it yet. I often use this trace for sanity checking of
changes to glretrace,
I am trying to get some regression tests to run in Xvfb. On my
workstation, the GL_VERSION string from this is:
1.4 (2.1 Mesa 7.7.1)
according to glxinfo. The extensions fairly clearly show 2.x features.
Is it perhaps the case that 2.1 features were available in 7.7.1, but
not /all/ 2.1 featu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 19 Jun 2011 22:58:18 -0700, Eric Anholt wrote:
Non-text part: multipart/signed
> On Sun, 19 Jun 2011 14:51:28 -0700, Chad Versace wrote:
> > On Sun, 19 Jun 2011 10:15:49 -0700, Eric Anholt wrote:
> > Non-text part: multipart/signed
> > > On
https://bugs.freedesktop.org/show_bug.cgi?id=38454
--- Comment #1 from Pascal Billery-Schneider
2011-06-20 09:23:52 PDT ---
Forget to give some information about my configuration:
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R2
https://bugs.freedesktop.org/show_bug.cgi?id=38501
--- Comment #1 from Sven Arvidsson 2011-06-20 08:36:51 PDT ---
Created an attachment (id=48196)
--> (https://bugs.freedesktop.org/attachment.cgi?id=48196)
backtrace from MESA_GLSL=dump crash
--
Configure bugmail: https://bugs.freedesktop.org/u
https://bugs.freedesktop.org/show_bug.cgi?id=38501
Summary: [glsl] Infinite loop when running Bioshock
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 19 Jun 2011 02:56:51 -0700, Kenneth Graunke
wrote:
> On 06/17/2011 03:43 PM, Chad Versace wrote:
> > Hiz buffer allocation can only occur if the 'else' branch has been taken,
> > so move the hiz buffer allocation into the 'else' branch.
> >
>
Probably it's missing the .def files too...
I think that instead of manually listing source files in mesa/Makefile we
should invoke 'git ls-files' (and maybe manually list any exclusions).
Splitting out Mesa GLUT from the source tree would make things much easier.
Which is probably a sensible
On Mon, Jun 20, 2011 at 02:39:39AM +0200, Marek Olšák wrote:
> Pushed, thanks.
Thank you.
> The other patch should be pushed by someone who understands it (i.e. not me).
>
> You already have 36 commits in Mesa master. You should really apply
> for an account.
Ok, I will apply.
Thanks again.
Ma
36 matches
Mail list logo
