headers
bugzilla-daemon | 1 May 2005 01:44

[Bug 3165] texImage.IsCompressed and texImage.CompressedSize issues

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3165          

------- Additional Comments From brian.paul <at> tungstengraphics.com  2005-04-30 16:44 -------
(In reply to comment #2)
> (In reply to comment #1)
> > I guess I was expecting that the driver itself would plug in the correct
> > InternalFormat and IsCompressed values when needed.  In practice, I believe this
> > would only be needed when the user's internalFormat was one of the six generic
> > compressed formats.  In that case, the driver chooses the best specific
> > compressed format, or falls back to an uncompressed format.  The spec says that
> > the GL then replaces internalFormat's value with the actual chosen format.
> 
> Is it actually necessary to change the internalFormat? I thought it was merely a
> hint to the OpenGL implementation with respect to the internal representation of
> the image.

Normally, the user's internalFormat is just a hint and the value is kept as-is
in the texture image's state record.  But in the case of texture compression,
when the user's internalFormat is a generic format, we want to store the actual
internal format chosen by the driver so that the user can ask OpenGL what format
it really settled on.  That's my reading of the spec.

> For example a driver that can't do RGB can fall back to an RGBA
> format without changing the internalFormat.

Yes, that's true.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 May 2005 01:29

[Bug 3165] texImage.IsCompressed and texImage.CompressedSize issues

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3165          

------- Additional Comments From rscheidegger <at> gmx.ch  2005-04-30 16:29 -------
This is exactly the problem I had when I tried to implement an option to always
enable texture compression even on textures which are not compressed (not
exactly legal, but for performance reasons and commercial drivers may do it too,
results were mixed though since the cpu overhead for on-the-fly generated
textures was way too high). I considered the workarounds for it hackish though,
and dropped it in later versions of the patches. IIRC I simply added code to
reinitialize the IsCompressed field (the crashes were due to incorrect size
calculations).          

     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 May 2005 16:05

[Bug 3170] New: Segfault in check_input_stages in t_pipeline.c

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3170          

           Summary: Segfault in check_input_stages in t_pipeline.c
           Product: Mesa
           Version: CVS
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Mesa core
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: fxkuehl <at> gmx.de

I was able to reproduce this problem with the Savage driver each time after
accepting changes on Setup-System-Graphics settings screen in Quake3 demo:

Program received signal SIGSEGV, Segmentation fault.
0xb396ac28 in _tnl_run_pipeline (ctx=0x8427878) at tnl/t_pipeline.c:84
84            if (tnl->vb.AttribPtr[i]->size != tnl->pipeline.last_attrib_size[i] ||
(gdb) print tnl->vb.AttribPtr
$9 = {0x862a97c, 0x862ab28, 0x862a998, 0x862a9b4, 0x862a9d0, 0x862a9ec,
  0x862abb4, 0x862abd0, 0x862aa08, 0x862aa24, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
  0x862accc, 0x862ace8, 0x862ad04, 0x862ad20, 0x862ad3c, 0x862ad58, 0x862ad74,
  0x862ad90, 0x862adac, 0x862adc8, 0x862ade4, 0x862ae00, 0x862aae8, 0x0, 0x0}
(gdb) print i
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 May 2005 18:58

[Bug 3165] texImage.IsCompressed and texImage.CompressedSize issues

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3165          

------- Additional Comments From fxkuehl <at> gmx.de  2005-05-01 09:58 -------
(In reply to comment #4)
> > Is it actually necessary to change the internalFormat? I thought it was merely a
> > hint to the OpenGL implementation with respect to the internal representation of
> > the image.
> 
> Normally, the user's internalFormat is just a hint and the value is kept as-is
> in the texture image's state record.  But in the case of texture compression,
> when the user's internalFormat is a generic format, we want to store the actual
> internal format chosen by the driver so that the user can ask OpenGL what format
> it really settled on.  That's my reading of the spec.

You're right. Reading the spec made a few things clearer.

> > I think I'd like to take this a bit further. Can we add an IsCompressed field to
> > the gl_texture_format and move function CompressedTextureSize from ctx->Driver
> > to gl_texture_format?
> 
> That sounds good, actually.  But I'd rename CompressedTextureSize() to just
> TextureSize() since the former wouldn't apply to uncompressed formats but the
> later would apply to all kinds of formats.

Ok.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 May 2005 21:47

[Bug 3170] Segfault in check_input_stages in t_pipeline.c

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3170          

------- Additional Comments From katerinab <at> gmail.com  2005-05-01 12:47 -------
I appear to be hitting the same bug.  My card is r200 based; I'm using the open
source radeon driver under xorg 6.8.2.  Running opencroquet with xorg 6.8.2's
mesa, I hit the failed assertion discussed at
https://bugs.freedesktop.org/long_list.cgi?buglist=836 .  With today's (May 1st,
2005) mesa cvs, I have the same bug as the poster here.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209607968 (LWP 9985)]
Error while running hook_stop:
Invalid type combination in ordering comparison.

0xb78fcd7f in check_input_changes (ctx=0x82fa960) at t_pipeline.c:84
84            if (tnl->vb.AttribPtr[i]->size != tnl->pipeline.last_attrib_size[i] ||

gdb> bt
#0  0xb78fcd7f in check_input_changes (ctx=0x82fa960) at t_pipeline.c:84
#1  0xb78fce1d in _tnl_run_pipeline (ctx=0x81670b0) at t_pipeline.c:128
#2  0xb7871316 in r200WrapRunPipeline (ctx=0x81670b0) at r200_state.c:2316
#3  0xb799c41c in _tnl_draw_range_elements (ctx=0x81670b0, mode=0x4,
max_index=0x82fa960, index_count=0x82fa960, indices=0x82fa960) at t_array_api.c:104
#4  0xb799ca1d in _tnl_DrawElements (mode=0x4, count=0xfc, type=0x1405,
indices=0x2506ce50) at t_array_api.c:372
#5  0xb78f6207 in neutral_DrawElements (mode=0x82fa960, count=0x82fa960,
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 May 2005 22:17

[Bug 3170] Segfault in check_input_stages in t_pipeline.c

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3170          

------- Additional Comments From michel <at> daenzer.net  2005-05-01 13:17 -------
Shouldn't the Mesa CVS commit below have fixed this?

CVSROOT:        /cvs/mesa
Module name:    Mesa
Repository:     Mesa/src/mesa/tnl/
Changes by:     keithw <at> gabe.    05/04/25 02:36:27

Log message:
  Ensure all VB->AttribPtr[] are populated.  Reported by Aapo Tahkola

Modified files:
      Mesa/src/mesa/tnl/:
        t_array_import.c 

  Revision      Changes    Path
  1.45          +18 -8     Mesa/src/mesa/tnl/t_array_import.c
  http://cvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_array_import.c          

     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         

------- You are receiving this mail because: -------
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 May 2005 23:03

[Bug 3170] Segfault in check_input_stages in t_pipeline.c

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3170          

------- Additional Comments From fxkuehl <at> gmx.de  2005-05-01 14:03 -------
(In reply to comment #2)
> Shouldn't the Mesa CVS commit below have fixed this?

No, it didn't. The code handling texture units in _tnl_vb_bind_arrays looks a
bit fishy:

   for (index = 0; index < VERT_ATTRIB_MAX; index++) {
      /* ... */
      else if (index >= VERT_ATTRIB_TEX0 && index <= VERT_ATTRIB_TEX7) {
         for (i = 0; i < ctx->Const.MaxTextureUnits; i++) {
            _tnl_import_texcoord( ctx, i, GL_FALSE, GL_FALSE );
            tmp->TexCoord[i].count = VB->Count;
            VB->AttribPtr[_TNL_ATTRIB_TEX0 + i] = &tmp->TexCoord[i];
         }
      }
      /* ... */
   }

This will only initialize used texture units and it will initialize them
multiple times (depending on how many texture units are used).

Anyway, is it really necessary to initialize all attributes? check_input_changed
seems to be the only function that has a problem with NULL pointers. I guess the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob (=Jouk) Jansen | 2 May 2005 11:46
Picon
Picon

test if mail to sourceforge works again

Hi,

Please ignore

This is just a test to see if my problems with sending mail to sourceforge
are solved.

      Jouk

Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  joukj <at> hrem.stm.tudelft.nl

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Kavli Institute of Nanoscience       tttttttttt  uu     uu  dd    dd
  Nationaal centrum voor HREM              tt      uu     uu  dd     dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2782272                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 2 May 2005 15:15

[Bug 3170] Segfault in check_input_stages in t_pipeline.c

Please do not reply to this email: if you want to comment on the bug, go to    

the URL shown below and enter yourcomments there.     

https://bugs.freedesktop.org/show_bug.cgi?id=3170          

------- Additional Comments From aet <at> rasterburn.org  2005-05-02 06:15 -------
(In reply to comment #3)
> Anyway, is it really necessary to initialize all attributes? check_input_changed
> seems to be the only function that has a problem with NULL pointers. I guess the
> only person who really knows what's going on here is Keith though. ;-)

AFAIK, Mesa handles situations where vertex shader requests for certain attrib
but user didnt pass it with this.          

     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Permalink | Reply | 0 comments |
headers
Brian Paul | 2 May 2005 16:56

Re: update on GL_EXT_framebuffer_object work


This weekend I finished updating the DRI drivers to work with the new 
framebuffer/renderbuffer changes.  My DRI test system is terribly out 
of date so I haven't run any tests.  I'm tempted to just check in the 
changes now and help people fix any problems that arise, rather than 
spend a few days updating my test box.  I think the code changes are 
pretty safe though.

Here's a summary of changes to the DRI drivers:

1. GLframebuffer creation changes:

    Create a "drirenderbuffer" for each color/depth/stencil buffer.
    Attach drirenderbuffers to the GLframebuffer.
    Add software-based renderbuffers.

    See r200_screen.c r200CreateBuffer() for example.

2. Span function changes:

    Span functions now get plugged into the renderbuffers, not the
    swrast module.
    Updated the parameters of the spantmp.h, spantmp2.h and
    depthtmp.h files.

    See r200_span.c for example.

After these changes are in and tested, there's some follow-on work:

1. Remove all old/dead code framebuffer/span code, marked
(Continue reading)

Permalink | Reply | 0 comments |

Gmane