| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
|
| |
_eglConfigFromContextModesRec is used to convert a __GLcontextModes to a
_EGLConfig. Note that the config is not validated. An invalid mode
is likely to give an invalid config.
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
| |
Make it similiar to how contexts and surfaces are looked up. It should
be slightly faster, and work better with multiple displays.
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
|
| |
This mainly implements the algorithms for configuration selection and
sorting, described in the spec. User errors should also be correctly
detected and reported.
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Config keys are almost config attributes. A valid config attribute is a
valid config key, but a valid config key may not be a valid config
attribute.
This commit does not distinguish the differences.
Signed-off-by: Chia-I Wu <[email protected]>
|
|
|
|
|
|
|
| |
Note that llvmpipe still doesn't run on any processor yet: if you don't
have a recent processor with SSE4.1 you will still likely end up
hitting a code path for which a generic non-sse4 version is not
implemented yet.
|
|
|
|
|
|
|
|
|
|
| |
I was waiting for the need to use this code to arise, and it finally came.
I've tested building this on Linux and Windows, both x86 and x64_64. But
it might break other platforms. Please bear with me and help me fix it.
Many thanks to Dennis Smit who submitted this, and Eric Anholt whose
work this was based on.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
gcc 4.4 seems particularly picky with int -> enum conversions.
|
|
|
|
|
|
| |
makes blend functions work better
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
Makes doom3 alot nicer..
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This whole reuse of buffers (TexSubImage instead of TexImage, SubData
instead of Data) is bad for hardware drivers, but it's even worse when
we accidentally try to access the 2x2 PBO to fill the new 16x16 texture
we're creating, producing GL errors.
Fixes piglit pbo-drawpixels. Bug #14163.
|
| |
|
| |
|
|
|
|
|
| |
In guess_and_alloc_texture() use the gl_texture_object::GenerateMipmap
field as another hint as to whether to allocate space for a whole mipmap.
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49
I'm not certain that this is entirely the correct fix since the demo
from bug #23774 seemed to work before the commit that broke the build.
Signed-off-by: Robert Noland <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The main issue is we didn't always have a gallium texture object with
enough space to store the to-be-generated mipmap levels. When that's
the case, allocate a new gallium texture and use st_texure_finalize()
to copy images from the old texture to the new one.
We also had the baseLevel parameter to st_render_mipmap() wrong.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't compute the st_texture_object::lastLevel field based on the texture
filters. Use the _MaxLevel value that core Mesa computes for us.
When called from the GenerateMipmap path, we'll use the lastLevel field
as-is.
|
| | | |
|
| | |
| | |
| | |
| | | |
Bug #23760 (crashes in wine)
|
| | |
| | |
| | |
| | | |
Avoids an unnecessary fallback.
|
| | | |
|
| | |
| | |
| | |
| | | |
Based on softpipe commit a77226071f6814a53358a5d6caff685889d0e4ec.
|
| | | |
|
| | |
| | |
| | |
| | | |
pipe/p_compiler for integer types. No declarations out of scope.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
why there are two input position semantic tags is that ureg doesn't
set vs input semantic due to commit: 6d8dbd3d1ec888
so use vs input index instead of semantic name.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
It could be generated by vertex shader.
|
| | |
| | |
| | |
| | | |
Not sure why we are getting a shader with two inputs with position semantic, but we don't know how to handle it correctly so it's better to stop the app than lock the machine.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Not 100% sure this is correct, but its more correct than what was here previous
however it may require changes in the input routing for the frag shader.
|
| | | |
|
| | | |
|