[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    [Mesa3d-dev] [Bug 3165] texImage.IsCompressed and texImage.CompressedSize issues
From:       bugzilla-daemon () freedesktop ! org
Date:       2005-04-30 23:44:13
Message-ID: 20050430234413.C255D9E7C2 () gabe ! freedesktop ! org
[Download RAW message or body]

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@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.


> I thought the same could work for compressed vs. uncompressed formats.

I think the generic compression formats are an exception.

 
> > If you think calling _mesa_init_teximage_fields() later in the glTexImage
> > process would be better, that's OK with me.
> 
> I'm not sure if the fields set in _mesa_init_teximage_fields aren't needed
> earlier, so I'd try to avoid moving _mesa_init_teximage_fields. I was rather
> thinking to initialize IsCompressed and CompressedSize outside that function.
> And is_compressed_format should decide by the chosen gl_texture_format instead
> of the internalFormat.

I think you're right.

 
> >  Maybe it should go in the
> > _mesa_texstore() routines after the actual texture format has been chosen.
> 
> Yes.
> 
> >  And
> > maybe the internalFormat parameter to ctx->Driver.ChooseTextureFormat() should
> > be passed via a pointer so the routine can change it if needed.
> 
> I don't think this is needed. See above.
> 
> > 
> > Maybe you should go ahead and try that out and see how it works.
> > 
> 
> 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.


> I'd have to check if other drivers make their own
> gl_texture_formats and adjust them accordingly along with the texture formats in
> core Mesa. This should make it easy to add more (driver-specific) compressed
> formats in the future without any further changes in core Mesa.

Right.  I don't have time to work on this but I encourage you to look into it. 
If you can provide a patch, I will review it and test it out with various tests
before it's committed.  Please take a look at the texture compression docs to
see if you agree about replacing the internalFormat value for generic formats.

Sounds like these changes would help with Roland's problem too.
          
     
     
--           
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
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[prev in list] [next in list] [prev in thread] [next in thread]