Closed
Bug 942951
Opened 11 years ago
Closed 10 years ago
WebGL assertion failure as WebGLContext::GetBitsPerTexel hits unexpected format GL_RGB32F
Categories
(Core :: Graphics: CanvasWebGL, defect)
Core
Graphics: CanvasWebGL
Tracking
()
RESOLVED
FIXED
mozilla29
People
(Reporter: bjacob, Assigned: jgilbert)
Details
(Whiteboard: webgl-assert)
Attachments
(1 file)
1.80 KB,
patch
|
bjacob
:
review+
|
Details | Diff | Splinter Review |
STR: 1. Make a *debug* build 2. Visit WebGL Pasta: http://alteredqualia.com/three/examples/webgl_pasta.html 3. Go to about:memory and hit 'measure' Result: assertion failure: #5 <signal handler called> #6 0x00007f36be42f0df in mozilla::WebGLContext::GetBitsPerTexel (format=34837, type=5126) at /hack/mozilla-central/content/canvas/src/WebGLContextValidate.cpp:522 #7 0x00007f36be447ef5 in mozilla::WebGLTexture::ImageInfo::MemoryUsage (this=0x7f3694019b28) at /hack/mozilla-central/content/canvas/src/WebGLTexture.cpp:51 #8 0x00007f36be447fef in mozilla::WebGLTexture::MemoryUsage (this=0x7f36940d6060) at /hack/mozilla-central/content/canvas/src/WebGLTexture.cpp:68 #9 0x00007f36be43638a in mozilla::WebGLMemoryReporterWrapper::GetTextureMemoryUsed () at /hack/mozilla-central/content/canvas/src/WebGLMemoryReporterWrapper.h:72 #10 0x00007f36be42a733 in WebGLMemoryReporter::CollectReports (this=0x7f368e727c70, aCb=0x7f365ec85460, aClosure=0x0) at /hack/mozilla-central/content/canvas/src/WebGLContextReporter.cpp:38 (gdb) frame 6 #6 0x00007f36be42f0df in mozilla::WebGLContext::GetBitsPerTexel (format=34837, type=5126) at /hack/mozilla-central/content/canvas/src/WebGLContextValidate.cpp:522 522 MOZ_ASSERT(false); (gdb) l 460 455 ErrorInvalidValue("%s: width and height must be >= 0", info); 456 return false; 457 } 458 459 if (width > maxAllowedSize || height > maxAllowedSize) { 460 ErrorInvalidValue("%s: the maximum texture size for level %d is %d", info, level, maxAllowedSize); 461 return false; 462 } 463 464 return true; (gdb) 465 } 466 467 uint32_t WebGLContext::GetBitsPerTexel(GLenum format, GLenum type) 468 { 469 // If there is no defined format or type, we're not taking up any memory 470 if (!format || !type) { 471 return 0; 472 } 473 474 if (format == LOCAL_GL_DEPTH_COMPONENT) { (gdb) 475 if (type == LOCAL_GL_UNSIGNED_SHORT) 476 return 2; 477 else if (type == LOCAL_GL_UNSIGNED_INT) 478 return 4; 479 } else if (format == LOCAL_GL_DEPTH_STENCIL) { 480 if (type == LOCAL_GL_UNSIGNED_INT_24_8_EXT) 481 return 4; 482 } 483 484 if (type == LOCAL_GL_UNSIGNED_BYTE || type == LOCAL_GL_FLOAT) { (gdb) 485 int multiplier = type == LOCAL_GL_FLOAT ? 32 : 8; 486 switch (format) { 487 case LOCAL_GL_ALPHA: 488 case LOCAL_GL_LUMINANCE: 489 return 1 * multiplier; 490 case LOCAL_GL_LUMINANCE_ALPHA: 491 return 2 * multiplier; 492 case LOCAL_GL_RGB: 493 case LOCAL_GL_SRGB_EXT: 494 return 3 * multiplier; (gdb) 495 case LOCAL_GL_RGBA: 496 case LOCAL_GL_SRGB_ALPHA_EXT: 497 return 4 * multiplier; 498 case LOCAL_GL_COMPRESSED_RGB_PVRTC_2BPPV1: 499 case LOCAL_GL_COMPRESSED_RGBA_PVRTC_2BPPV1: 500 return 2; 501 case LOCAL_GL_COMPRESSED_RGB_S3TC_DXT1_EXT: 502 case LOCAL_GL_COMPRESSED_RGBA_S3TC_DXT1_EXT: 503 case LOCAL_GL_ATC_RGB: 504 case LOCAL_GL_COMPRESSED_RGB_PVRTC_4BPPV1: (gdb) 505 case LOCAL_GL_COMPRESSED_RGBA_PVRTC_4BPPV1: 506 return 4; 507 case LOCAL_GL_COMPRESSED_RGBA_S3TC_DXT3_EXT: 508 case LOCAL_GL_COMPRESSED_RGBA_S3TC_DXT5_EXT: 509 case LOCAL_GL_ATC_RGBA_EXPLICIT_ALPHA: 510 case LOCAL_GL_ATC_RGBA_INTERPOLATED_ALPHA: 511 return 8; 512 default: 513 break; 514 } (gdb) 515 } else if (type == LOCAL_GL_UNSIGNED_SHORT_4_4_4_4 || 516 type == LOCAL_GL_UNSIGNED_SHORT_5_5_5_1 || 517 type == LOCAL_GL_UNSIGNED_SHORT_5_6_5) 518 { 519 return 16; 520 } 521 522 MOZ_ASSERT(false); // ### CRASH HERE! ### 523 return 0; 524 } (gdb) p/x format $7 = 0x8815 // GL_RGB32F (gdb) p/x type $8 = 0x1406 // GL_FLOAT The question is how did we end up with GL_RGB32F as the format here? That is not a valid 'format' parameter to WebGL.texImage2D, even with OES_TEXTURE_FLOAT. Is this a format/internalformat mismatch i.e. are we recording an internalformat of RGB32F here? If yes, does the present function need to be updated to accept such internalformat values?
Reporter | ||
Updated•11 years ago
|
Flags: needinfo?(dglastonbury)
Benoit, Following the STR I was unable to reproduce. Is there more to it?
Flags: needinfo?(dglastonbury)
Reporter | ||
Comment 2•11 years ago
|
||
OK, nevermind then, thanks for trying, but if this doesn't reproduce for you then there's probably nothing that you can do about this bug; I'll try to take a look.
Assignee | ||
Updated•10 years ago
|
Whiteboard: webgl-assert
Assignee | ||
Comment 4•10 years ago
|
||
Attachment #8356329 -
Flags: review?(bjacob)
Reporter | ||
Updated•10 years ago
|
Attachment #8356329 -
Flags: review?(bjacob) → review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 5•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b50e11876aee Please make sure that future patches include a commit message when requesting checkin.
Keywords: checkin-needed
Comment 6•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b50e11876aee
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in
before you can comment on or make changes to this bug.
Description
•